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)

Ну что же, круто, хотя в принципе, и до этого особых проблем не было благодаря checkinstall. В рассылку-то написал?

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

Нет, до рассылок я пока ещё не добрался.

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

debuild

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

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

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

В случае деббилдов используется связка *.DebBuild и control, где control - обычный Debian'овский control файл.

Ну и нахрена тогда этот дебилд нужен? Если всё-равно писать control, то можно добавить ещё пару файлов в папке debian/ и собрать по-нормальному через dpkg-buildpackage.

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

Каких скриптов?

Которые в rules. Не все осиливают такие форматы, включая форматы .spec файлов для rpm'а и ебилдов. А обычные скрипты просты и понятны.

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

А что тут осиливать? Вот мой для xarchiver:

#!/usr/bin/make -f

%:
	dh $@ --parallel --with autotools_dev

override_dh_auto_configure:
	dh_auto_configure -- --libexecdir=/usr/lib

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

А что тут осиливать?

Макросы и прочие target'ы. Даже чтобы их увидеть нужно начать курить документацию. В общем, непонятно с какой стороны и в каком порядке оно начинает выполняться и как конкретно раскрывается.

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

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

А что тут непонятного? Берёшь и смотришь скрипты, если припрёт. А так две строчки в rules. Зачем ещё один велосипед?

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

Для написания твоих скриптов её тоже надо курить. А, кстати, где она?

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

Для написания твоих скриптов её тоже надо курить. А, кстати, где она?

В том и суть, что деббилды как и слакбилды - простые скрипты на bash'е, и тут если и нужна документация, то по bash'у и командам UNIX.

А что тут непонятного?

Макросы всегда непонятны. Например, кто бы мог подумать, что

%configure
в .spec файле - это не разделитель секций, а макрос, который раскрывается везде по-разному, например, так:
  CFLAGS="${CFLAGS:--O2 -g}" ; export CFLAGS ; 
  CXXFLAGS="${CXXFLAGS:--O2 -g}" ; export CXXFLAGS ; 
  FFLAGS="${FFLAGS:--O2 -g}" ; export FFLAGS ; 
  ./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu \
        --program-prefix= \
        --disable-dependency-tracking \
        --prefix=/usr \
        --exec-prefix=/usr \
        --bindir=/usr/bin \
        --sbindir=/usr/sbin \
        --sysconfdir=/etc \
        --datadir=/usr/share \
        --includedir=/usr/include \
        --libdir=/usr/lib64 \
        --libexecdir=/usr/lib/x86_64-linux-gnu \
        --localstatedir=/var \
        --sharedstatedir=/usr/com \
        --mandir=/usr/share/man \
        --infodir=/usr/share/info

В общем, обычные скрипты дают больше низкоуровневого контроля.

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

Другой более сложный формат же.

Ты дурак? Вся сложность там в controls который тебе всё-равно нужен. При этом вмето корявой простыни что ты привёл в «новости» получаем компактное стандартное описание, которое понимают все дебьяновские утилиты.

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

И в чём сложность файла control? Достаточно набросать около 9-ти строчек, можно даже, например, так:

Package: apl
Priority: optional
Section: devel
Installed-Size:
Maintainer: my name
Architecture: amd64
Version: 1.7
Depends:
Description: GNU APL is a free interpreter for the programming language APL.
Installed-Size подкорректируется автоматически, Depends бинарников по дефолту тоже.

компактное стандартное описание, которое понимают все дебьяновские утилиты

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

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

А я уж обрадовался что control-файл не нужен. А по-факту - не совсем понятна цель этого скрипта. Собирать свежий софт из сырцов? Так есть же Linuxbrew, например. Да и если цель избавиться от rules-файла - так это смотря что собирать.

Sunderland93 ★★★★★
()

Будут по умолчанию встроены в EEEbuntu - Ubuntu для ASUS EEE PC

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

> А что тут осиливать?

Во времена Debian 4 и 5 было просто и понятно. В более новых релизах - хочешь добавить параметр configure, открываешь rules, а там нету. Открываешь все файлы подряд, а там тоже нету. Наконец, делаешь поиск по содержимому файлов

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

Помню у нас в шапке давно извращались с nosrc.rpm ...

Ну допустим в слаке я понимаю как это пашет, а как это скрипт притащит все что нужно для сборки ?

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

в .spec файле - это не разделитель секций, а макрос, который раскрывается везде по-разному, например, так:

Значит так нужно для данного дистрибутива. Непонятно, по какой причине ты решил эти правила проигнорировать и развести помойку в /usr

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

Во времена Debian 4 и 5 было просто и понятно. В более новых релизах - хочешь добавить параметр configure, открываешь rules, а там нету. Открываешь все файлы подряд, а там тоже нету. Наконец, делаешь поиск по содержимому файлов

Что люди не придумывают, чтобы не читать Debian Policy Manual

anonymous
()

Прочитал тред, но так и не понял, какие преимущества дает твой велосипед по сравнению со штатными средствами сборки. Аргумент «сложный формат, не все осиливают, надо читать доки» просто смешон.

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

Значит так нужно для данного дистрибутива. Непонятно, по какой причине ты решил эти правила проигнорировать

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

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

это скрипт притащит все что нужно для сборки ?

Разумеется, нет, как и слакбилды ничего не притаскивают.

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

так и не понял, какие преимущества

Значит, именно Вам деббилды ненужны. А другим, которые мыслят так:

у вашего дебиана наркоманская система сборки пакетов

, деббилды нужны.

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

я уж обрадовался что control-файл не нужен.

control файл control файлу рознь. Деббилды не требуют control файлов на сотни или десятки строк. Достаточно около 9-ти, как минимум 2 из которых подправятся автоматически (см. выше).

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

О спасибо.

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

Разумеется, нет, как и слакбилды ничего не притаскивают.

Вы меня конечно извините ( и может меня сейчас слакварщики запинают ) но слака в отличии от дебиана дистрибутив без зависимостей. И такой фокус тут не прокатит.

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

Без установленных нужных библиотек ничего не скомпилится и не запустится в любом дистрибутиве, в т.ч. и в Slackware. Так что, сборочные зависимости нужно везде устанавливать. А вот деббилды, в отличие от слакбилдов, вписывают зависимости бинарников в итоговые пакеты (можно отключать и вписывать зависимости вручную), и вот эти вот зависимости итогового пакета при его установке притянуты будут.

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

Без установленных нужных библиотек ничего не скомпилится и не
запустится в любом дистрибутиве,

Ну значит я использую какие то левые дисрибутивы в виде Шапки. У нас тут в mock ( минимальное изолированное окружение ) сырцы ставятся, тащут себе все что им нужно для сборки, потом делают рпм пакеты с нужными им зависимостями для работы.

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

А вот деббилды, в отличие от слакбилдов, вписывают зависимости бинарников в итоговые пакеты (можно отключать и вписывать зависимости вручную)

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

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

Ничего нового твой деббилд не представляет.

Деббилды и должны быть принципиально старыми. Слакбилдам уже не один десяток лет, а это тоже самое только для Debian'а.

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

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

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

Это я понимаю. В слаке без зависимостей собрал чего либо ССЗБ, а в дистрибутиве с зависимостей я считаю все должно уже быть предусмотрено мантейнерами данного пакета.

А то решишь патч накатить и что нужно 2 часа выяснять с чем его собирать ?

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

Ну так в имеющемся control файле уже могут быть перечислены зависимости. При выполнении деббилд заполняет эту строку, и это задача маинтейнера чтобы он заполнил её правильно (при том, что зависимости бинарников и так вписываются автоматически). Хотя в другой deb-based системе зависимости могут быть уже несколько другими. При заполнении зависимостей makedeb составляет список нужных библиотек, а потом смотрит каким пакетам они принадлежат. И если в другом дистрибутиве эти библиотеки будут в других пакетах, то придётся составлять зависимости заново.

В общем, проверять работу деббилдов маинтейнер всё равно должен, а при этом список зависимостей таки составляется. И вполне можно выкладывать control файлы с уже заполненными зависимостями, как лично я и делаю:

Package: apl
...
Depends: libc6 (>= 2.19), libgcc1 (>= 1:4.9.2), libncurses5 (>= 5.9), libstdc++6 (>= 4.9.2), libtinfo5 (>= 5.9)
Package: telegram-purple
...
Depends: libc6 (>= 2.19), libdbus-1-3 (>= 1.8.22), libdbus-glib-1-2 (>= 0.102), libfarstream-0.1-0 (>= 0.1.2), libffi6 (>= 3.1), libgadu3 (>= 1:1.12.0), libgcrypt20 (>= 1.6.3), libglib2.0-0 (>= 2.42.1), libgmp10 (>= 2:6.0.0), libgnutls-deb0-28 (>= 3.3.8), libgpg-error0 (>= 1.17), libgstreamer0.10-0 (>= 0.10.36), libgstreamer-plugins-base0.10-0 (>= 0.10.36), libhogweed2 (>= 2.7.1), libidn11 (>= 1.29), liblzma5 (>= 5.1.1alpha), libnettle4 (>= 2.7.1), libp11-kit0 (>= 0.20.7), libpcre3 (>= 2:8.35), libprotobuf-c1 (>= 1.0.2), libpurple0 (>= 2.11.0), libselinux1 (>= 2.3), libtasn1-6 (>= 4.2), libwebp5 (>= 0.4.1), libxml2 (>= 2.9.1), zlib1g (>= 1:1.2.8.dfsg)

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

Есть build-dep, если я правильно понял то, что ты спрашиваешь.

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

Наркоман штоле? Деббилды не умеют ничего, что умеют уже отточенные инструменты сборки deb-пакетов. Деббилды не предоставляют никаких новых фич.

Слакбилдам уже не один десяток лет, а это тоже самое только для Debian'а

В дебиане этого не нужно.

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

Деббилды не умеют ничего

Деббилды умеют всё, что в них было прописано, а в них можно прописать что угодно.

В дебиане этого не нужно.

Если не нужно лично Вам, то это не значит, что никому не нужно.

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

В арче всё как-то проще намного.

Но движение в правильном направлении. В следующей версии можно
- control засунуть прямо в переменные .DebBuild в #control variables (названия даже намекают)
- комменты типа #package заменить на bash-процедурки package() { ... }.
Затем переименовать DebBuild в PKGBUILD, пропихнуть это в апстрим.
- репу на гитхабе сделать редиректом на aur.archlinux.org, и тогда дебианом станет можно иногда пользоваться.

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

./configure --prefix=/usr && make
dh_make --createorig
Добавить описание программы в файле debian/control
dpkg-buildpackage -rfakeroot
dpkg -i *.deb

Для сборки пакета с одной программой, которая не содержит библиотек, т.е. только бинарник в /usr/bin и данные в /usr/share должно хватить.

Horse
()

Ну ХЗ, я свои deb-ы собираю мэйкфайлом (потому-что классика, потому-что олдскул и скрепы) дёргающем dpkg-deb. Но у меня там всё тривиально до безобразия. Единственное что напрягает так это из одного проекта собирать разные типа пакетов для разных версий ОС (у меня там много завязок на релиз-специфичные вещи)

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

Кто говорит? ДЕБилы с ЛОР? Не слушай их.

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

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

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

Деббилды? Смеялся так последний раз после федоры на пи. Или чего там еще такое же было, только про дебиан?

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

название лучше не мог придумать
saahriktu

то есть УПШСВФ-15 v0.2 и те чудеса на бурятском тебя не смущали?

anonymous
()

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

anonymous_incognito, это действительно такая важная «технология», что нужно было нести её на главную?

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.