Comments 27
PROMPT approved.
На уровне "Имеем vim и ar"
А про описание на этом уровне — почему бы и нет. Был бы спрос.
извиняюсь, но разве ar, это не архиватор, который, в основном, используют для сборки кучки объектников в статическую библиотеку?
Дан код на питоне. Самописный, т.е. менять можно «под себя». Он предоставляет несколько модулей с main() внутри, т.е. может быть исполнен как программа. Нормальной практикой является использование setup.py с entry_points, которые задают console_script, который генерируется при установке пакета. setup.py использует stdeb, который настраивается pybuild'ом, который вызывается dh_python2(3) (с опцией --buildsystem=pybuild, который вызывается dpkg-buildpackage, который вызывается git-buildpackage, который вызывается build-and-provide скриптом debian-jenkins-glue, который вызывается jenkins'ом.
Задача: генерировать console_scripts не в /usr/bin, а в /usr/lib/other_app/plugins.
Как? Я эту проблему решил, причём довольно
https://www.debian.org/doc/debian-policy/ch-controlfields.html
То есть просто нужно дописать необходимые пакеты в правильные секции «заготовки» контрол файла.
Если нет — попробуйте удовлетворить dh_install с помощью файла «имя пакета».install (в каталоге debian).
Т.е. кладёте дерево нужных файлов (т.е. usr/bin/foo, usr/lib/libfoo-1.so), делаете debian/control, а в debian/foo.install пишите usr/bin/foo\nusr/lib/libfoo-1.so.
debian/rules при этом выглядит так:
%:
dh $@
debian/changelog можно заполнить с помощью dch -i.
А есть у кого инфа по созданию ярлыка (shortcut или desktop) на рабочем столе пользователя?
Интересует для deb пакета, чтобы ярлык был уже у существующих пользователей и у вновь регистрируемых (в скелетоне).
Как это правильно организовать...
Вообще, когда система описаний (спеков) для сборки требует таких вот статей, что-то не так (у самого несколько PPA). Самые адекватные спеки, по функциональности и возможностями, имхо, у ArchLinux, AlpineLinux (они позаимствовали идеи у Arch, но спеки не на 100% одинаковые). Прямо подмывает сделать прокси-makepkg для deb-based систем, который будет брать спек в формате PKGCONFIG
, генерировать инфраструктуру для dpkg-buildpackage и производить отстройку. Ну и возможность экспорта, что бы иметь возможность залить в тот же PPA.
Кстати, а никто не знает, вдруг подобное уже есть?
ArchLinux-пакеты не покрывают полностью функционал deb. reconfigure и update-alternatives как в Арче сделать?
А не про сами пакеты и пакетную систему речь.
Данные действия вызываются из maintainer скриптов (аналоги самих скриптов — есть). Кроме того, они никакого отношения к описанию процесса сборки через control/rules/changelog не имеют. Я именно про это, про спек, а не про сам пакетный менеджер или формат пакета писал.
Т.е. что бы сделать описание сборки под Арч, достаточно одного файла, с простой шапкой, двумя функциями (build и install) и интуитивными командами (всё таки это шелл). А в debian:
- сделать "дебианизацию" пакета исходного кода
- распаковать исходники
- создать директорию debian с rules, control, changelog, format/version
Далее заполнить вышеозначенные файлы. А у каждого из них свой формат, со своим хитрым набором целей (rules) или специальными утилитами для обновления (changelog + dch). Если для примитивного опакечивания в арчике нужно минут 5-10 на создание правил, причём информации в "рыбе" файла хватает с избытком, то для debian — у меня меньше получаса не получается.
Добавить сюда невозможность (хотя фича спорная) при пакетировании автоматического версифицирования для пакетов сборке которых происходит из исходников из VCS; плюс то что сборку можно делать разными способами: debian/rules, dpkg-buildpackage, debuild, то в части описания сборки PKGBUILD и makepkg всё же удобнее.
Про подписи не говорю, оно сейчас и там и там есть в разном виде.
PS и да, я не пользователь Арча, лет несколько как.
Создание пакета Debian с нуля