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)
Ответ на: комментарий от saahriktu

jdk проприетарен и распространяется уже собранными бинарниками.

вылазьте из криокамеры. openjdk довольно-таки давно официально является референсной реализацией, sun/oracle jdk нужно сильно далеко не всегда.

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

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

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

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

> saahriktu

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

Это анаграмма от, полагаю, a.kurash-it.

Ну или от kura-a-shit.

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

Еще раз нет, это слакбилды &etc на это заточены, а сам дистр бинарный.

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

отделение сборочных файлов в -dev пакеты всё усложняет

Сборочные зависимости — это не только -dev пакеты. Это ещё и компиляторы, кодогенераторы, всякие autotools и т.д.

А в случае наличия -dev пакетов их лучше сразу поставить ко всем библиотекам - и никаких проблем.

А, простите, зачем мне на рабочей машине всё это? Мне некуда место на диске девать? А если мы ставим систему на что-то встраиваемое с маленькой флешкой?

Отделение ПО от сборочных файлов даёт уменьшение количества «мусора» в системе. А держать всё в одной куче — глупость.

Рабочая машина — она для работы. А для сборки — сборочная система в чистом контейнере.

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

Ну так для роутеров и виртуальных машин надо пилить минималистичные дистрибутивы. А на десктопах всё должно быть из коробки. Или тогда не надо жаловаться на то, что требуется много сил и времени на вычисление -dev пакетов. В нормальных дистрибутивах, как Slackware и Crux, всё сразу из коробки.

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

Это анаграмма от, полагаю

Нет. Мой ник около 10-ти лет назад получен через мою утилиту для получения случайных ников (путём random'а).

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

Ну так для роутеров и виртуальных машин надо пилить минималистичные дистрибутивы

на кой фаллос этим заниматься при наличии дистрибутива, повторюсь, общего назначения? с чего вы взяли, что дебиан «десктопный»?

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

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

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

открою большой секрет: в подавляющем большинстве юзеры не тратят много сил на вычисление и установку dev пакетов, за ненадобностью им сего занятия. При сборке пакета штатными средствами оно все приползет само. Желающие собирать нечто из голых исходников предположительно имеют достаточную для этого квалификацию.

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

неверная логическая цепочка, даже при принятии за истину весьма спорного исходного высказывания)

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

Ну так для серверов никто Slackware и не рекомендует.

У «никто» имя есть? А то у мню чего-то работает более 10 лет и проблем не вижу.

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

Мой ник около 10-ти лет назад получен через мою утилиту для получения случайных ников (путём random'а).

Аааа я все понял, вы ее походу усовершенствовали до в0.2 с поддержкой UTF-8... срочно на главную в новости.

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

Речь шла именно про «рекомендовать». Большинство на серверах предпочитают обновления безопасности. А так-то, конечно, никто не против.

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

Но, не такие как в Debian'е. Подразумеваюися отдельные -security ветки при замороженных версиях пакетов. И для вообще всех имеющихся пакетов. В то время как slackbuilds.org уже выходит за рамки официального репозитория.

Вон, например, в дистрибутивах на днях пропатчили библиотеку strongswan. Кто её пропатчил в Slackware? Она даже не входит в базовую систему. Да, она есть на slackbuilds.org, но относительно старой версии. Маинтейнер обновил её год назад - и всё. И всем чихать. Только если сам возьмёшь и обновишься по собственной инициативе собственными силами. Ещё раз подчёркиваю, что в Debian'е 8 пропатчили версию 5.2.1, а в Debian'е 9 5.5.1, в то время как на slackbuilds.org версия 5.3.4.

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

Вон, например, в дистрибутивах на днях пропатчили библиотеку strongswan

Вы нашли самый «не смешной» пример. Ибо strongswan один из самых «не надежных» в части обновления, версия от версии приносит новые косяки. И как раз его, если используешь в проде лучше держать на одной версии. И только когда планируешь большое обновление сначала проверь(включая работу клиентов на разных ос и смартов), поправь везде конфиги, а потом обновляй.

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

Ну так тем больше нужно накладывать патчей, причём периодически. А в Слаке софт почти весь ванильный, особенно на slackbuilds.org. Как маинтейнер положил одну версию - так оно и будет висеть _без всяких патчей_ (т.е. и без security патчей, да) до новой версии через год-другой.

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

Но, многие предпочитают просто подключить -security ветку и не париться.

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

Вы не поняли? Нельзя переезжать с версии на версию автоматом. Только осознанное действие с предварительным тестированием. Что занимает не малое время.
Походу вы админ локалхоста.

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

Вы с какой стороны читаете? Я и говорю, например, про переезд с версии 5.2.1 без патчей на версию 5.2.1 с патчами. В Debian'е это есть через ветку -security. В Слаке же никаких веток -security нет. Год назад выложили версию 5.3.4 без патчей, и она так и будет 5.3.4 без патчей, пока кто-нибудь не выполнит недопустимое с Вашей точки зрения действие - не обновится до новой версии, например, 5.5.3 и опять же без патчей. Кто патчи-то писать будет?

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

Так с этим никто и не спорит, но за slackbuilds.org он не следит. Об этом и речь.

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

Спрошу просто, нах мне патч если он сломает мне работу? Т.е. лучше не станет, а вот хуже с немалой долей вероятности станет. Надеюсь так доступнее?

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

Что сломается если версия библиотеки не поменяется? В Debian'е это есть. В Слаке этого нет, но есть обновления до новых версий.

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

Мдя. Вы хоть понимаете что такое патч? Изменение кода и как следствие поведения - «Исправили старые баги, добавили новые» (с)
Да собстно вам в соседней теме пару патчей уже накидали.... готовьте новую версию в utf-8

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

Бывает, конечно, всякое. Тем не менее, от патчей безопасности уходят наиболее активно эксплуатируемые крякерами уязвимости. И именно поэтому они критичны для серверов. По крайней мере, так считается.

Но, можно, конечно, и без патчей сидеть.

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

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

Так их всегда вокруг полно было ¯\_(ツ)_/¯

anonymous
()

в самих деббилдах нет специфичных для Debian'а команд

ARCH=$(dpkg --print-architecture)
...
	for CURRENTBINARY in ${BINLIST} ; do
		for libfile in $(ldd ${CURRENTBINARY} | sed «s/^.*\ \//\//g;s/\ .*$//g») ; do
		debname=$(dpkg -S ${libfile} 2>/dev/null | tail -n 1 | \
			sed «s/:.*$//»)
		depslist+=$(apt-cache show ${debname} 2>/dev/null | \
        			grep ^Version | \
        sed «s/[\+-].*$//;s/^Version/${debname}/;s/:\ /\ \(>=\ /;s/$/\)/»)

Я чего-то не знаю о dpkg и apt-cache? Они появились в других дистрах?

N.B. Такой скрипт пишется за полчаса.

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

Я же написал «если»:

Если отслеживание зависимостей отключено, а в самих деббилдах нет специфичных для Debian'а команд

И именно потому, что эта процедура использует специфичные для Debian'а команды.

Такой скрипт пишется за полчаса.

Да хоть за 2 минуты. Почему-то до меня его именно в таком виде никто не написал. Да и теперь никому не надо тратить время на его написание - он уже есть.

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

Окай.

Запуск скрипта без опций сказал, что нужен какой-то action. Запуск скрипта с опциями -h или --help ничего не выдал. Как я должен узнать о том, что нужно отключать зависимости? Да. Я заглянул внутрь скрипта. Там какой-то ад и израиль с парсингом опций. После этого я понял, почему я даже при большом желании ничего бы не смог узнать о параметрах запуска.

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

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

Почему-то до меня его именно в таком виде никто не написал.

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

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

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

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

Я прочитал Debian Maintainer's Guide. Описанные там инструкции понятнее, чем в твоём README. Причём там про формат control тоже написано. У тебя нет. Из этого я делаю вывод, что пользователь твоего скриптика должен был ознакомиться с Debian Maintainer's Guide. Закономерный вопрос. Зачем твой скрипт?

По остальным пунктам возражений, я так понимаю, не возникло?

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

В файле control все поля названы своими именами и интуитивно понятны. Лично я никаких Debian Maintainer's Guide не читал, а ознакомился с форматом control файлов через выхлопы «apt-cache show». Можно, конечно, и из готовых пакетов их извлекать, но по сути разницы нет.

Зачем твой скрипт?

Для пакования файлов в .deb пакеты и других низкоуровневых операций с .deb пакетами. Заново сгенерировать md5 суммы, список зависимостей бинарников или пересобрать с новым control файлом без переупаковывания файлов заново - это всё его возможности, которые перечислены в Readme. И если это всё непонятно, то тут даже непонятно кто как разбирался.

По остальным пунктам

По каким ещё пунктам? Вы вообще поняли для чего этот скрипт? Его задача как и у makepkg - просто создавать пакеты. Всё остальное по необходимости вносится в деббилды.

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

Я чего-то не знаю о dpkg и apt-cache? Они появились в других дистрах?

В Федоре есть и dpkg, и apt-cache, и прочее в том же духе вроде dpkg-buildpackage. Специально для того, чтобы собирать deb-пакеты, не развертывая сборочные серверы на Дебиане.

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

alien занимается в первую очередь конвертированием пакетов.

Quasar ★★★★★
()

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

Они всегда тут были

Wizard_ ★★★★★
()

Деббилды, б! ©

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

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

Мне кажется у него угнали аккаунт.

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

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

Deleted
()

деббилды
ненужновелосидокостыль
saahriktu

И я совсем не удивлён.

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

Лично я никаких Debian Maintainer's Guide не читал

Ну и дурак

Deleted
()

зачем отдельный файл control если его секции можно задать в твоём файле-дебильнике

тогда все переменные были бы в одном файле

и вообще посмотри лучше как PKGBUILD-ы сделаны: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=telegram-purple

то же, что я написал сверху + команды сборки вынесены в функции для того чтобы иметь какое-то подобие АПИ

в таком виде это можно было бы задокументировать и надеяться что в твоём регистре появится более 3 пакетов

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

зачем отдельный файл control

Затем, что структура .deb файла подразумевает, что в нём присутствует архив control.tar.gz с файлами control и md5sums. Так что, файл control нужен в любом случае. Не для компиляции, а для пакета.

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

Зачем генерировать, если можно сразу взять готовые? Слакбилды используют отдельные slack-desc файлы, и никого это не смущает.

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

чтобы иметь единый файл и его формат — в текущем виде не совсем понятно различие между твоей поделкой и текущим путем сборки пакетов

так же, возвращаясь к PKGBUILD (да и ebuild-ам, чего уж там) — в твоих примерах я не вижу никакого референса к исходникам, которые надо опакетить, т.е. нет возможности гарантировать, что при следующем запуске что-то соберется

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

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

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

возвращаясь к PKGBUILD (да и ebuild-ам

Они тут ни при чём. Возвращаться надо к слакбилдам. В комплекте к которым прилагаются отдельные slack-desc файлы.

saahriktu ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.