Как стать автором
Обновить

Комментарии 40

Три статьи а меня все еще интересует вопрос, а нельзя ли это все какнить… упростить? Хотя бы гуёвину для формирования дерева и контрол-файлов. Мне редко нужно собирать пакеты и писать нечто под свои нужды смысла не имеет. Так вот и вопрос: Можно без консольного шаманства (которое меня не пугает, но все же) наклепать пакетов?

Вопрос два: можно создать мета-пакет с совершенно разными прогами и сразу завернутыми туда зависимостями?
Упростить можно :) Прочитайте, вдумайтесь, по мере чтения — создавайте шаблоны файлов, подходящие именно Вам. Оставьте там свои комментарии: личные заметки всегда понятнее любых статей. Получится скелет, который с минимальными изменениями копипастится для создания нового пакета, и урезается до необходимого минимума :)

А ещё проще — упомянутый checkinstall. Для простых пакетов подходит идеально :)
Ему не обязательно давать команду «make install» для дебианизации: это может быть и скрипт с «mv * /usr/local/bin». Чекинсталлу по барабану за чем наблюдать :)
Благодарю, это ясно. Упростить рутину — методы известны. Я просто на счет инструмента интересовался. Да, всякие там «мастера» — это не unix-way но иногда не очень хочется вникать в то, что один раз сделаешь и будешь лет пять использовать.
Верно. Человек ленив по своей природе :)
Я сейчас как раз работаю над интерактивной прогой (не мудрствуя, консольный php скрипт), которая задаёт юзеру вопросы и генерирует этот каркас пакета так, что останется лишь немножко подредактировать контрольный файл :) Когда она будет достаточно мощна для распространения и проверена — срелизну)
Если нет желания заморачиваться, то есть тот же checkinstall.
ICD2 подсказывает, что есть GUIшная прога для создания пакетов: GiftWrap :)
Брр, прозевал второй вопрос %)

Конечно можно!
Но принято создавать маленький пакет, зависящий от всех необходимых. В него также складываются все те вещи, которые предположительно меняются чаще остальных.
Например, для игр обычно главный пакет — архитектурозависимые бинарники: для них патчи выходят часто. А графика и звук раскладывается в завимимые отдельные пакеты: они обновляются реже, и пользователям не придётся качать всю графику снова :)
Кроме того, заворачивать все зависимости в один пакет — это очень уж по виндузятному :) Разрешение зависимостей придумывали как раз чтобы не заниматься подобной ерундой, у которой есть минимум один серьёзный недостаток: врядли вы будете обновлять все эти зависимости при выходе заплаток ;)
ага, совершенно виндузячья потребность. есть n пакетов, которые отсутствуют в репах. Нужно ставить все разом. Приходится делать что-то типа sudo dpkg -i ./*.deb && sudo apt-get install -f
Размер файла не критичен, а вот перекачивать все это… при обновлении зависимости и так обновятся через тот же apt-get upgrade.
Вот потому и хочется чтобы ставилось разом, а обновлялось раздельно. Можно написать скрипт, но как-то больше греет пакетик…
Именно поэтому я и описал простой способ создания собственного репозитория: просто добавьте ваши убежавшие зависимости в него, и всё установится как по маслу :)
Расшарить репозиторий апачем — задача тривиальная, и позволит устанавливать всю эту пачку на всех машинах в сети. А если эту болванку репозитория выкинуть на VDS… ;)
Это если есть сеть и/или инет.
В примере используется локальный репозиторий: ему не нужны никакие апачи :)
При добавлении репозитория вместо протокола http используется протокол file, и всё супер :)
Большой труд, спасибо :)
Сегодня просто день debian-пакетов :) В продолжение темы: mahoro.habrahabr.ru/blog/78086/

Все-таки создавать пакеты лучше всего на основе шаблонов. Там есть примеры использования debhelper'ов. Например, файл с чексуммами создается командой dh_md5sums, устнавливать файлы проще с dh_install (который позволит обойтись без sudo).

И еще, в ваших болванках скриптов не хватает проверки на то, какое действие собственно происходит. В случае с postinst-скриптом это вроде ничего, но в prerm это уже совсем не лишнее. Правильные шаблоны есть в dh_make.

Но за упоминание про set -e и set -u — отдельный респект :)
Признаюсь, с dh_* практически не знаком, пока оставил просто отсылку к мануалу :) Удобная должна быть штука, спасибо, разберусь :)
Спасибо, интересовался
Остаётся только заметить, что собирать свои собственные rpm — значительно более простое и приятное занятие.
Я, конечно, не имел дела с rpm, но что-то мне подсказывает, что вы просто не читали полную документацию возможностей :) Deb пакет тоже можно сделать ограничившись одним файлом: DEBIAN/control ;)
Не читал, и это не мешает мне собирать rpm-пакеты.
Огромный успех создателей формата, ящитаю.
А вот со сбором deb таким способом совершенно обломался.
Ожидал увидеть таки ман по dh_make
Если меня никто не опередит — в будущем сделаю отдельной статьёй :)
Для тех кто ниасилил консоль или по каким либо причинам не хочет ее использовать для создания deb пакетов, есть GUI утилита GiftWrap. Домашняя страница проекта. А так же страница на Launchpad.
Супер, спасибо! Добавил в статью :)
Пользуйтесь на здоровье :)
Папка вроде как должна быть «debian», а не «DEBIAN». Ни в одном пакете с исходниками, готовыми для сборки deb-пакетов, не видел папку «DEBIAN», везде только «debian». Это важно! :)
Спасибо, ща исправлю! увлёкся :))
Спасибо, полезная тема!
Огромное спасибо за тщательно разжеванный мануал. Тема уже не нова для Хабра, но так подробно никто еще не описывал, материала реально достаточно, чтобы собрать deb пакет даже tar архиватором.
в дебиане есть в меню папка Debian. думаю, если прописывать в конфиге, то иконка там и появляется. а для нормального меню, как я понял, нужно создать файл в /usr/share/menu/
Угу, «нормальное меню» – рабочий стандарт *.desktop файла, называется 'Desktop Entry' :) В KDE также используется для контекстных меню. Рекомендую почитать коротенькую спецификацию: standards.freedesktop.org/desktop-entry-spec/latest/, там есть немало полезных свойств :)
я так и думал. но не стал называть .desktop, расширений у файлов в этой директории нету
при попытке собрать пакет выпадает ошибка:
dpkg-deb: ошибка: каталог control имеет недопустимые права доступа
Наткнулся на рекурсивную зависимость:
Грубо говоря я делаю патч, который надо накатить поверх основной версии, но основная версия живет в стороннем репозитории, получается схема моего deb пакета:
preinst скрипт добавляет новый репозиторий, ставит из него основной пакет, а потом уже мой deb подменяет 1 бинарник.

Это как должно работать в идеале, но из preinst скрипта нельзя вызвать aptitude команду, соответственно после того как я сделал echo 'репозиторий' > /etc/apt/sources.list.d/app.conf кэш не обновлялся и установка пакета от которого зависит мой пакет не проходит, я получаю сообщение:
This package is uninstallable
Dependency is not satisfiable: nginx (= 1.8.0-1~precise)


Есть идеи как обойти эту рекурсию?
$ md5deep -l -o f -r usr -r etc > DEBIAN/md5sums

md5sums для нескольких директорий(несколько -r) + выставление относительных путей(-l) + обработка только файлов(-o f), т.к. симлинки и директории не нужны
Пишу из 2019. Прошло 10 лет, а статья всё ещё актуальная. Только чо собрал свой первый deb-пакет.

Большое спасибо за такую подробную информацию!
ldd ./MyProject выдает много библиотек которые нужны приложению для запуска. Стоит ли добавлять их все, или есть какие-то правила в построении зависимостей?

ldd выдаёт транзитивные зависимости — то есть все библиотеки, которые будут загружены при запуске процесса. В зависимости пакета следует добавлять только прямые зависимости: те библиотеки, которые непосредственно нужны вашему приложению, но не включая те, которые нужны зависимостям ваших зависимостей.


Прямые зависимости можно посмотреть по записям DT_NEEDED, например, вот так:


$ readelf --dynamic /bin/bash | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

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


dh_shlibdeps умеет определять список пакетов и необходимые версии автоматически. Если собираете пакет вручную, то придётся делать это вручную.

Спасибо за ответ. А как поступать в таком случае: в процессе запуска приложения после установки пакета обнаружилось, что не хватает библиотеки libssl1.0.0, однако, в Linux Mint 19.3 пакет этой версии присутствует, а уже Linux Mint 20 есть новая версия libssl1.1, а старой версии нет совсем в репозитории. При этом, если в мой пакет добавить зависимость libssl1.0.0 (>= 1.0.2), то в Mint 20 зависимость менеджер пакетов не может разрешить. Приложение жестко привязано к версии библиотеки. Как поступать: добавлять в пакет недостающий файл библиотеки? Я так понимаю, что если я так установлю пакет на Linux Mint 19.3, а потом удалю его, то и файлы библиотеки удалятся, которые могут сломать другие приложения и зависимости в репозитории?

У пакета libssl намеренно меняется название, когда меняется ABI библиотеки (а у OpenSSL он может меняться с каждым мажорным релизом — когда меняется первая или вторая цифра версии). Это делается именно для того, чтобы случайно не сломать какой-нибудь другой пакет, который зависит от libssl (>= 1.0.2), если вдруг окажется, что в OpenSSL 1.1 у какой-то функции изменился интерфейс.


В общем случае следует собирать отдельные пакеты для Mint 19 и Mint 20, каждый из которых зависит от своей версии библиотеки. Так поступают дистрибутивы со своей пакетной базой.


Если вам не хочется собирать и распространять несколько версий, то — если приложение позволяет — можно указать альтернативные зависимости, например: libssl1.0.0 (>= 1.0.2) | libssl1.1 (>= 1.1.1f). В таком случае пакетный менеджер устроит либо libssl1.0.0, либо libssl1.1. Но так можно делать только если вы уверены, что приложение действительно может работать с обеими версиями и не использует функции, у которых изменился интерфейс. Но скорее всего так не получится, потому что у библиотек будет разный soname и приложение не сможет загрузить libssl1.1: ему нужна будет libcrypto.so.1.0.2, а в системе только libcrypto.so.1.1.

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