LINUX.ORG.RU

Появились деббилды

 ,


6

3

Деббилды для Debian'а — тоже самое, что и слакбилды для Slackware. Это простые скрипты, которые собирают пакеты.

В отличие от makepkg, деббилды используют скрипт makedeb, который по дефолту отслеживает зависимости бинарников и включает их в .deb пакет. Если отслеживание зависимостей отключено, а в самих деббилдах нет специфичных для Debian'а команд, то деббилды должны успешно собирать .deb пакеты в любых дистрибутивах, поскольку makedeb собирает пакеты низкоуровнево (через ar + tar + ... и т.д.).

Например, вот таким скриптом может быть собран telegram-purple:

#!/bin/bash
# 2017 (c) Artem Kurashov <mail@saahriktu.org> under GNU GPLv3

#control variables
PKGNAM=telegram-purple
VERSION=$(ls $PKGNAM*.tar.?z* | cut -d _ -f 2 | cut -d . -f 1-3)
ARCH=$(dpkg --print-architecture)
BUILD=${BUILD:-1}

#adjust control file
sed -i "s/^Architecture:.*$/Architecture: $ARCH/" control
sed -i "s/^Version:.*$/Version: $VERSION/" control

#building
tar xvf $PKGNAM*.tar.?z*
cd $PKGNAM
./configure --prefix=/usr --libdir=/usr/lib
make

#packaging
mkdir ../data
DESTDIR="../data" make install
cd ../data
makedeb ep ${PKGNAM}_${VERSION}-${BUILD}_${ARCH}.deb

#cleaning
cd ..
rm -r control.tar.gz data data.tar.lzma debian-binary md5sums $PKGNAM
Здорово, правда?

В случае слакбилдов основными являются 2 главных файла: *.SlackBuild и slack-desc. В случае деббилдов используется связка *.DebBuild и control, где control — обычный Debian'овский control файл. Деббилды могут править control файл, с которым потом будет собран пакет. Скрипт makedeb в любом случае правит control файл, в т.ч. вписывая в него зависимости бинарников, а уже после этого собирает с ним пакет. Как видно, всё очень просто.

makedeb можно скачать здесь (.deb пакет со скриптом прилагается): makedeb-0.5.tar.gz
первый в мире репозиторий деббилдов (пока что содержит 3 рабочих деббилда для apl, purple-vk-plugin и telegram-purple): https://github.com/saahriktu/saahriktu-debbuilds

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: anonymous_incognito (всего исправлений: 3)
Ответ на: комментарий от anon1337

Нет, это не самое главное. У того, кто активно собирает пакеты, в большинстве случаев и так уже всё есть.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

А на другом компе? А другим людям? Смысл всех танцев теряется, это ж мне самому разбираться в том, что требуется для сборки (а это не всегда явно указано в каком-то README). Остальное я и сам сделать могу, да даже руками, а вот сборочные зависимости в рецепте — это хорошее дело.

anon1337
()
Ответ на: до сих пор не освоил, как их собирать от Horse

Т.е освоить целый дистрибутив, предназначающийся для опытных пользователей, проще, чем один менеджер пакетов. Ты прав, я с тобой в этом согласен. Но это о многом говорит, не в пользу менеджера пакетов.

Rinaldus ★★★★★
()
Последнее исправление: Rinaldus (всего исправлений: 1)
Ответ на: комментарий от anon1337

Я ж уже писал выше. При тестировании деббилда можно оставить результат правильного заполнения зависимостей в control файле, который тоже часть деббилда.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от Rinaldus

Он же сказал, что НЕ сложнее. Освоил генту — освоишь и сборку пакетов в дебиане, ничего там особенно сложного. Документация есть достаточно хорошая, инструментов полно.

anon1337
()
Ответ на: комментарий от anon1337

Случаи, конечно, бывают разные. И про ряд из них сложно сходу узнать даже маинтейнерам. Например, может быть так, что у маинтейнера всё собралось и работает, а у другого человека с другой версией дистрибутива не работает поскольку у него, например, версия cmake другая. Или версии библиотек немного не совпали. Хотя теоретически должно было взлететь.

Конечно, в таких случаях может быть хорошим тоном описывать сборочные зависимости отдельно.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Я это к тому, что обычно подобные рецепты включают в себя сборочные зависимости. Разве нет? Просто у дебиана сборочные зависимости обычно явно выделены в пакеты с суффиксом «-dev».

anon1337
()

Ждем когда автор этого добра откопает труп emerde(был такой порт гентушного emerge для Слаки) и начнет новости про него вываливать на главную.

ergil ★★★
()
Ответ на: комментарий от anon1337

Разделение на кучу мелких пакетиков - это, кстати, огромный минус deb-based и rpm-based дистрибутивов. В Slackware более правильный подход. Поэтому сборочные зависимости слакбилдов на slackbuilds.org (а они там во многих случаях указываются), выглядят, например, так: «This requires: muParser, qwt5, qwtplot3d». Никаких -dev. Если библиотеки и софт установлены, то в системе уже есть всё, что нужно для разработки с ними.

saahriktu ★★★★★
() автор топика

Твой ник скоро станет нарицательным:

Насаахриктить - написать корявый баш скрипт на 10 строк

Поймать саахрикту - прокрастинировать

Саахриктный - кривой, глупый

Делать из системы Саахриктукс - превращать дистр в слаку

anonymous
()
Ответ на: комментарий от saahriktu

Не все осиливают такие форматы

Практически все. Ну да есть отдельные ламеры, которые даже элементарный Makefile понять не могут, но нельзя же всех по себе судить-то. С другой стороны, что ещё ожидать от недоучки, не осилившего юникод.

zabbal ★★★★★
()
Ответ на: комментарий от anc

Ну зачем вы так обижаете ТС?

От брезгливости.

см. соседнюю тему про УПШСВФ-15

Ага, перерутать последовательную шину с параллельной это хорошая заявка на победу.

Мне откровенно противно от осознания, что с ростом популярности GNU/Linux, подобная воинствующая безграмотность пытается корчить из себя разработчика:

Даже чтобы их увидеть нужно начать курить документацию.

zabbal ★★★★★
()
Ответ на: комментарий от saahriktu

Разделение на кучу мелких пакетиков - это, кстати, огромный минус deb-based и rpm-based дистрибутивов. В Slackware более правильный подход.

Ты опять все перепутал.

dexpl ★★★★★
()
Ответ на: комментарий от saahriktu

Это не минус, ведь дебиан — бинарный дистрибутив. В слаке такое оправдано по очевидным причинам. Сборка же пакетов в дебиане носит эпизодический характер.

anon1337
()
Ответ на: комментарий от zabbal

Ага, перерутать последовательную шину с параллельной это хорошая заявка на победу.

Комментарии в той теме можите и не читать, но посмотрите исходники... думаю доставит...
Хотяяя коменты тоже интересные, во всяком случае хорошее настроение обеспечено. :)

anc ★★★★★
()
Ответ на: комментарий от anon1337

дебиан — бинарный дистрибутив

Slackware тоже бинарный дистрибутив. Среди юзеров любого дистрибутива есть те, кому нужно собирать в т.ч. и своё, а жёсткие диски уже давно не 700 Мб, и файлы для разработки никого не задавят.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Slackware тоже бинарный дистрибутив.

Ну, я бы поспорил. Возможность такая есть, но основная часть пользователей всё же собирает софт из исходников.

файлы для разработки никого не задавят

Равно как и установка их содержащих пакетов никого не задавит. Незачем тащить то, что по дефолту не нужно.

anon1337
()
Ответ на: комментарий от anon1337

установка их содержащих пакетов никого не задавит

Но, это дополнительные силы и время, и не все хотят их тратить, выбирая в итоге дистрибутив из ряда Slackware и Gentoo. Хотя могли бы выбрать Debian или CentOS.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от anon1337

Slackware тоже бинарный дистрибутив.

Ну, я бы поспорил.

И я бы с вами поспорил, слака как дистр бинарный и точка. Все остальное можно рассматривать и применительно к другим дистрам.

anc ★★★★★
()
Ответ на: комментарий от saahriktu

файлы для разработки никого не задавят

Не всем это нужно.

dexpl ★★★★★
()
Ответ на: комментарий от saahriktu

Я же говорю, сборка пакетов в дебиане носит эпизодический характер, т.к. большая часть пользователей большую часть времени пользуется бинарными пакетами. Разработчики и мейнтейнеры же знают, что им нужно, и имеют в системе нужные «-dev» пакеты перманентно.

anon1337
()
Ответ на: комментарий от saahriktu

а жёсткие диски уже давно не 700 Мб, и файлы для разработки никого не задавят

Добро пожаловать в 2017-й год, вполне могут задавить для овер много независимых виртуалок.

anc ★★★★★
()
Ответ на: комментарий от anc

Ок, база бинарная, но заточен он всё же под компиляцию софта из исходников. Слакбилды, порты, куцые бинарные репозитории, вот это всё.

anon1337
()

Понял кто автор по второму предложению))

NextGenenration ★★
()

Я не спорю, в бебиане всё довольно плохо со сборкой пакетов, все эти чекинсталлы для тех, кто не знает, куда же пакет ставит либы или дебутстрап, использующий низкоуровневые тулзы типа ar и гзип для создания окружения это издец, но не настолько же.

siraenuhlaalu
()

Ахтунг, уровень упоротости полтора поттеринга!

Pisaahriktux уже был? Был.

Ждём антивируса Попова Курашова.

Bass ★★★★★
()
Ответ на: комментарий от saahriktu

Разделение на кучу мелких пакетиков - это, кстати, огромный
минус deb-based и rpm-based дистрибутивов.

Не согласен. К примеру вот я гляжу у себя сейчас : rpm -qa | grep java-1.8.0 java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64 java-1.8.0-openjdk-headless-1.8.0.131-3.b12.el7_3.x86_64

А знаете сколько весит ВСЯ жаба 1.8.0

Или к примеру тот же либре офисс. Зачем мне 150 языков ? И какой нибудь либро-драв :(

P.S. Помню давно с удивлением обнаружил что в Слаке по сути только 2 установки. Либо чел ставит БАЗЕ и ничего более ( как правило сервак ), либо как рабочий стол ставит ВСЕ ! :(

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)

Теперь шутку про букву «Д» не в том месте слова «ебилд» успешно портируют на Debian.

spijet ★★★
()

Пидору (федору для rpi) уже вспоминали?

anonymous
()
Ответ на: комментарий от mx__

В Slackware при установке можно поставить или убрать галочки _на каждом пакете_. Просто так делать не особо рекомендуется, поскольку большинству юзеров нужен KDE, да и при сборке софта (или даже при юзании) можно внезапно обнаружить отсутствие той или иной библиотеки. Но, если юзер желает, то можно поставить _любое_ сочетание пакетов. А не «только 2 установки». И такие люди как я могут, например, убрать галочки с того же KDE при установке.

Или к примеру тот же либре офисс. Зачем мне 150 языков ?

Вот поэтому его и надо собирать из исходников, указывая список нужных языков. А для этого файлы для разработки в системе должны быть.

А знаете сколько весит ВСЯ жаба 1.8.0

В Slackware jdk. И jdk-8u131-x86_64 весит, например, 364 Мб. И что? Жёсткий диск не 700 Мб же. Можно наставить много тяжёлых вещей, и не выйти за пределы, например, 20 Гб.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от saahriktu

В Slackware при установке можно поставить или убрать
галочки _на каждом пакете_.
...

Это я знаю, но для этого я должен хорошо знать что мне нужно и для чего.

И вообще мы тут выходим из темы, и я понимаю что сырцы это хорошо, а кто будет потом за обновлениями следить ? Или нужно каждый день что то собирать ? В той же яве практически каждый день дыру очередную закрывают, и если на трафик теперь чихать ( хотя в случае сырцов он минимален только патч, но в рпм и так минимален так как дельта-рпм валятся ) но я не думаю что 384 мега жабы соберутся быстро.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

jdk проприетарен и распространяется уже собранными бинарниками. Он только перепаковывается под каждый дистрибутив. Дольше всего собираются Firefox, Chromium, LibreOffice, webkit, phantomjs,... и другие тяжёлые вещи.

а кто будет потом за обновлениями следить ? Или нужно каждый день что то собирать ?

Новые версии выходят далеко не каждый день. Да и патчи безопасности в Slackware никто особо не тянет. Ну так для серверов никто Slackware и не рекомендует. Slackware хорошо подходит для десктопа за роутером, который блокирует доступ к машине. Или для машин без интернета вообще.

saahriktu ★★★★★
() автор топика

дебиана не может быть много по определению

kto_tama ★★★★★
()

лучше портируйте пакетный менеджер пакман на слаку, это было бы действительно круто

anonymous
()

Автор, похоже, совершенно не понимает что такое «сборочные зависимости». А это вовсе не то что показывает ldd. Это вот что:

Build-Depends:
 debhelper (>= 9),
 dh-autoreconf,
 quilt (>= 0.40),
 pkg-config,
 libdrm-dev (>= 2.4.69) [!hurd-any],
 libx11-dev,
 x11proto-gl-dev (>= 1.4.14),
 libxxf86vm-dev,
 libexpat1-dev,
 …
и ещё пара десятков таких пакетов.

То есть, «сборочные зависимости», как не трудно понять из названия — то что нужно именно для сборки программы, а не для её последующей работы. И обычно все эти пакеты на рабочей машине не нужны, они как раз и устанавливаются в чистом окружении с помощью pbuilder.

anonymous
()
Ответ на: комментарий от saahriktu

Ты checkinstall глянь. Несколько раз в треде вспомнили уже. Он не то же самое делает, что твоя деббилда? Вроде как раз то же самое, не?

vitalif ★★★★★
()
Ответ на: комментарий от anonymous

обычно все эти пакеты на рабочей машине не нужны

Тем, кто так считает, с деббилдами просто не по пути.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от vitalif

checkinstall просто опакечивает же. Без учёта контрольной информации, включая зависимости. Деббилды же собираются вместе с control файлами.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Тем, кто так считает, с деббилдами просто не по пути.

Очень умно. Вот то есть, понадобилось человеку собрать пакет с telegram-purple, а он, к примеру, не программист вовсе, или программист, но не знает что конкретно нужно этой библиотеке. И что, это повод послать его к чёрту? Гениально! Ничего умнее предложить ему нельзя?

anonymous
()
Ответ на: комментарий от anonymous

Так я ж и говорю, что отделение сборочных файлов в -dev пакеты всё усложняет, а особенно для тех, кто программистами не являются. Если бы их не отделяли, то сборочные файлы ко всем библиотекам и так бы шли из коробки, и их можно было бы не вычислять. А в случае наличия -dev пакетов их лучше сразу поставить ко всем библиотекам - и никаких проблем.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)

Осталось портаж прикрутить, и заживём.

ass ★★★★
()
Ответ на: комментарий от zabbal

А мне вот кажется что «воинствующая безграмотность пытается корчить из себя разработчика» — это когда выкатывают «приложения» на мерзотном Electron, т.к. кроме javascript его создатели, видимо обучавшиеся по курсам youtube, ничего не знают и оправдывают это ссылкой на год «ой, сейчас же 2017, все так делают».

Вот это надо поносить и гнать таких гитхабодетей взашей обратно в их телеграм. А bash+Tk это даже православно.

anonymous
()

Модератор деббилд кек)

anonymous
()
Ответ на: комментарий от Knigochey

В Almohazzem есть кнопки «Packaging from folder» и «Packaging from source»
тыкал ради интереса в первую кнопку, он собрал мне .deb, .rpm и .tgz

hitode
()
Ответ на: комментарий от saahriktu

Вот поэтому его и надо собирать из исходников, указывая список нужных языков. А для этого файлы для разработки в системе должны быть.

все уже собрано «мелкими пакетиками»

root@tween-arkhost:~# aptitude search libreoffice | grep l10n
v  libreoffice-l10n-4.3 - 
v  libreoffice-l10n-5.2 - 
p  libreoffice-l10n-af - office productivity suite -- Afrikaans language package
p  libreoffice-l10n-am - office productivity suite -- Amharic language package
... 90 строк ...
p  libreoffice-l10n-zu - office productivity suite -- Zulu language package
arkhnchul ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.