Комментарии 40
Три статьи а меня все еще интересует вопрос, а нельзя ли это все какнить… упростить? Хотя бы гуёвину для формирования дерева и контрол-файлов. Мне редко нужно собирать пакеты и писать нечто под свои нужды смысла не имеет. Так вот и вопрос: Можно без консольного шаманства (которое меня не пугает, но все же) наклепать пакетов?
Вопрос два: можно создать мета-пакет с совершенно разными прогами и сразу завернутыми туда зависимостями?
Вопрос два: можно создать мета-пакет с совершенно разными прогами и сразу завернутыми туда зависимостями?
Упростить можно :) Прочитайте, вдумайтесь, по мере чтения — создавайте шаблоны файлов, подходящие именно Вам. Оставьте там свои комментарии: личные заметки всегда понятнее любых статей. Получится скелет, который с минимальными изменениями копипастится для создания нового пакета, и урезается до необходимого минимума :)
А ещё проще — упомянутый checkinstall. Для простых пакетов подходит идеально :)
Ему не обязательно давать команду «make install» для дебианизации: это может быть и скрипт с «mv * /usr/local/bin». Чекинсталлу по барабану за чем наблюдать :)
А ещё проще — упомянутый checkinstall. Для простых пакетов подходит идеально :)
Ему не обязательно давать команду «make install» для дебианизации: это может быть и скрипт с «mv * /usr/local/bin». Чекинсталлу по барабану за чем наблюдать :)
Благодарю, это ясно. Упростить рутину — методы известны. Я просто на счет инструмента интересовался. Да, всякие там «мастера» — это не unix-way но иногда не очень хочется вникать в то, что один раз сделаешь и будешь лет пять использовать.
Верно. Человек ленив по своей природе :)
Я сейчас как раз работаю над интерактивной прогой (не мудрствуя, консольный php скрипт), которая задаёт юзеру вопросы и генерирует этот каркас пакета так, что останется лишь немножко подредактировать контрольный файл :) Когда она будет достаточно мощна для распространения и проверена — срелизну)
Я сейчас как раз работаю над интерактивной прогой (не мудрствуя, консольный php скрипт), которая задаёт юзеру вопросы и генерирует этот каркас пакета так, что останется лишь немножко подредактировать контрольный файл :) Когда она будет достаточно мощна для распространения и проверена — срелизну)
Если нет желания заморачиваться, то есть тот же checkinstall.
Брр, прозевал второй вопрос %)
Конечно можно!
Но принято создавать маленький пакет, зависящий от всех необходимых. В него также складываются все те вещи, которые предположительно меняются чаще остальных.
Например, для игр обычно главный пакет — архитектурозависимые бинарники: для них патчи выходят часто. А графика и звук раскладывается в завимимые отдельные пакеты: они обновляются реже, и пользователям не придётся качать всю графику снова :)
Кроме того, заворачивать все зависимости в один пакет — это очень уж по виндузятному :) Разрешение зависимостей придумывали как раз чтобы не заниматься подобной ерундой, у которой есть минимум один серьёзный недостаток: врядли вы будете обновлять все эти зависимости при выходе заплаток ;)
Конечно можно!
Но принято создавать маленький пакет, зависящий от всех необходимых. В него также складываются все те вещи, которые предположительно меняются чаще остальных.
Например, для игр обычно главный пакет — архитектурозависимые бинарники: для них патчи выходят часто. А графика и звук раскладывается в завимимые отдельные пакеты: они обновляются реже, и пользователям не придётся качать всю графику снова :)
Кроме того, заворачивать все зависимости в один пакет — это очень уж по виндузятному :) Разрешение зависимостей придумывали как раз чтобы не заниматься подобной ерундой, у которой есть минимум один серьёзный недостаток: врядли вы будете обновлять все эти зависимости при выходе заплаток ;)
ага, совершенно виндузячья потребность. есть n пакетов, которые отсутствуют в репах. Нужно ставить все разом. Приходится делать что-то типа sudo dpkg -i ./*.deb && sudo apt-get install -f
Размер файла не критичен, а вот перекачивать все это… при обновлении зависимости и так обновятся через тот же apt-get upgrade.
Вот потому и хочется чтобы ставилось разом, а обновлялось раздельно. Можно написать скрипт, но как-то больше греет пакетик…
Размер файла не критичен, а вот перекачивать все это… при обновлении зависимости и так обновятся через тот же apt-get upgrade.
Вот потому и хочется чтобы ставилось разом, а обновлялось раздельно. Можно написать скрипт, но как-то больше греет пакетик…
Именно поэтому я и описал простой способ создания собственного репозитория: просто добавьте ваши убежавшие зависимости в него, и всё установится как по маслу :)
Расшарить репозиторий апачем — задача тривиальная, и позволит устанавливать всю эту пачку на всех машинах в сети. А если эту болванку репозитория выкинуть на VDS… ;)
Расшарить репозиторий апачем — задача тривиальная, и позволит устанавливать всю эту пачку на всех машинах в сети. А если эту болванку репозитория выкинуть на VDS… ;)
Большой труд, спасибо :)
Сегодня просто день debian-пакетов :) В продолжение темы: mahoro.habrahabr.ru/blog/78086/
Все-таки создавать пакеты лучше всего на основе шаблонов. Там есть примеры использования debhelper'ов. Например, файл с чексуммами создается командой dh_md5sums, устнавливать файлы проще с dh_install (который позволит обойтись без sudo).
И еще, в ваших болванках скриптов не хватает проверки на то, какое действие собственно происходит. В случае с postinst-скриптом это вроде ничего, но в prerm это уже совсем не лишнее. Правильные шаблоны есть в dh_make.
Но за упоминание про set -e и set -u — отдельный респект :)
Все-таки создавать пакеты лучше всего на основе шаблонов. Там есть примеры использования debhelper'ов. Например, файл с чексуммами создается командой dh_md5sums, устнавливать файлы проще с dh_install (который позволит обойтись без sudo).
И еще, в ваших болванках скриптов не хватает проверки на то, какое действие собственно происходит. В случае с postinst-скриптом это вроде ничего, но в prerm это уже совсем не лишнее. Правильные шаблоны есть в dh_make.
Но за упоминание про set -e и set -u — отдельный респект :)
Спасибо, интересовался
Остаётся только заметить, что собирать свои собственные rpm — значительно более простое и приятное занятие.
Спасибо, добавил в закладки.
P.S. В майском номере Linux Format была подобная статья:
Кому интересно:
pic.ipicture.ru/uploads/091213/1gN9WxSV1F.jpg
pic.ipicture.ru/uploads/091213/6ccT4iL9Zu.jpg
P.S. В майском номере Linux Format была подобная статья:
Кому интересно:
pic.ipicture.ru/uploads/091213/1gN9WxSV1F.jpg
pic.ipicture.ru/uploads/091213/6ccT4iL9Zu.jpg
НЛО прилетело и опубликовало эту надпись здесь
Ожидал увидеть таки ман по 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/, там есть немало полезных свойств :)
при попытке собрать пакет выпадает ошибка:
dpkg-deb: ошибка: каталог control имеет недопустимые права доступа
dpkg-deb: ошибка: каталог control имеет недопустимые права доступа
Наткнулся на рекурсивную зависимость:
Грубо говоря я делаю патч, который надо накатить поверх основной версии, но основная версия живет в стороннем репозитории, получается схема моего deb пакета:
preinst скрипт добавляет новый репозиторий, ставит из него основной пакет, а потом уже мой deb подменяет 1 бинарник.
Это как должно работать в идеале, но из preinst скрипта нельзя вызвать aptitude команду, соответственно после того как я сделал echo 'репозиторий' > /etc/apt/sources.list.d/app.conf кэш не обновлялся и установка пакета от которого зависит мой пакет не проходит, я получаю сообщение:
Есть идеи как обойти эту рекурсию?
Грубо говоря я делаю патч, который надо накатить поверх основной версии, но основная версия живет в стороннем репозитории, получается схема моего 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)
Есть идеи как обойти эту рекурсию?
НЛО прилетело и опубликовало эту надпись здесь
Пишу из 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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как собрать бинарный deb пакет: подробное HowTo