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

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

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

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

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

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

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

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

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

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

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

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

Там зависимости пакета ведь, а не сборочные. Разве нет? Просто это разные вещи.

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 ()

Я не спорю, в бебиане всё довольно плохо со сборкой пакетов, все эти чекинсталлы для тех, кто не знает, куда же пакет ставит либы или дебутстрап, использующий низкоуровневые тулзы типа 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 ★★★ ()
Ответ на: комментарий от siraenuhlaalu

saahriktu
siraenuhlaalu

ребят у вас там че, секта какая-то чтоли?

anonymous ()

Пидору (федору для 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 ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.