Comments 40
Вопрос два: можно создать мета-пакет с совершенно разными прогами и сразу завернутыми туда зависимостями?
А ещё проще — упомянутый checkinstall. Для простых пакетов подходит идеально :)
Ему не обязательно давать команду «make install» для дебианизации: это может быть и скрипт с «mv * /usr/local/bin». Чекинсталлу по барабану за чем наблюдать :)
Я сейчас как раз работаю над интерактивной прогой (не мудрствуя, консольный php скрипт), которая задаёт юзеру вопросы и генерирует этот каркас пакета так, что останется лишь немножко подредактировать контрольный файл :) Когда она будет достаточно мощна для распространения и проверена — срелизну)
Конечно можно!
Но принято создавать маленький пакет, зависящий от всех необходимых. В него также складываются все те вещи, которые предположительно меняются чаще остальных.
Например, для игр обычно главный пакет — архитектурозависимые бинарники: для них патчи выходят часто. А графика и звук раскладывается в завимимые отдельные пакеты: они обновляются реже, и пользователям не придётся качать всю графику снова :)
Кроме того, заворачивать все зависимости в один пакет — это очень уж по виндузятному :) Разрешение зависимостей придумывали как раз чтобы не заниматься подобной ерундой, у которой есть минимум один серьёзный недостаток: врядли вы будете обновлять все эти зависимости при выходе заплаток ;)
Размер файла не критичен, а вот перекачивать все это… при обновлении зависимости и так обновятся через тот же apt-get upgrade.
Вот потому и хочется чтобы ставилось разом, а обновлялось раздельно. Можно написать скрипт, но как-то больше греет пакетик…
Расшарить репозиторий апачем — задача тривиальная, и позволит устанавливать всю эту пачку на всех машинах в сети. А если эту болванку репозитория выкинуть на VDS… ;)
Все-таки создавать пакеты лучше всего на основе шаблонов. Там есть примеры использования debhelper'ов. Например, файл с чексуммами создается командой dh_md5sums, устнавливать файлы проще с dh_install (который позволит обойтись без sudo).
И еще, в ваших болванках скриптов не хватает проверки на то, какое действие собственно происходит. В случае с postinst-скриптом это вроде ничего, но в prerm это уже совсем не лишнее. Правильные шаблоны есть в dh_make.
Но за упоминание про set -e и set -u — отдельный респект :)
P.S. В майском номере Linux Format была подобная статья:
Кому интересно:
pic.ipicture.ru/uploads/091213/1gN9WxSV1F.jpg
pic.ipicture.ru/uploads/091213/6ccT4iL9Zu.jpg
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)
Есть идеи как обойти эту рекурсию?
Большое спасибо за такую подробную информацию!
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
умеет определять список пакетов и необходимые версии автоматически. Если собираете пакет вручную, то придётся делать это вручную.
У пакета 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.
Как собрать бинарный deb пакет: подробное HowTo