Comments 185
to kekekeks Новый формат пакетов а арче xz? Если да, то внутри тоже самое что и было просто более сильно пожатое.
Проще чем сборка пакета в арче из PKGBUILD — при помощи makepkg вообще не в одном дистрибутиве не видел. Простой bash-скрипт поэтапной сборки пакета — начисто лишенный обращения к каким либо макросам, из всего что нужно знать — это названия переменных с которыми работает makepkg(архитектура, корневой каталог, каталог с исходниками, каталог с файлами пакета и т.д.). Потому: если, даже в общих чертах, знаешь bash — научиться писать PKGBUILD-ы дело 30-ти минут, тем более готовых «шпаргалок» огромное количество в ABS и AUR.
пс:
Тоже по сути наболело: раньше часто приходилось писать spec-файлы для «синтеза» rpm пакетов. Так вот писать PKGBUILD-ы после spec-ов: все равно что есть руками после использования кучи бесполезных и неудобных, но специализированных, костылей для каждого блюда.
community/checkinstall 1.6.2-1
зы. Какой у вас сложный и интересный способ сборки DEBIAN'овских пакетов. (:
Я всю жизнь собирал через dh_make и dpkg-buildpackage -rfakeroot. На мой взгляд, гораздо удобнее, разве что иногда приходится повозиться с некоторым софтом, потому что часть файлов забывает включаться в пакет.
Спасибо.
Давно в курсе что make install зло — но вот как-то руки не доходили до сборки пакетов собственноручно, хотя оказываеться все гораздо проще чем я предполагал.
www.debian.org/doc/manuals/maint-guide/index.en.html
export DH_OPTIONSВы мне предлагаете в статье объяснять, где что и как править, чтобы добавить туда свои опции?
%:
dh $@
Тем более файл debian/rules
На этапа dh_auto_build автоматически вызовется make -f Makefile в родительской директории с уже правильно установленной переменной окружения DISTDIR и все файлы соберуться в нужной директории и будут упаковы
Нужно только немного напрячься и почитать man`ы по SPEC файлам ;)
Откройте для себя силу OpenSuSE Build Service (https://build.opensuse.org/), собирает RPM и DEB пакеты, имеет уже кучу собранных.Слушайте, у меня 3 ppa-шки на ланчпаде, не надо мне рассказывать, как правильно писать сценарии сборки пакетов. В статье предложен упрощённый способ, как это сделать быстро, имея результаты сборки из дерева исходников и не включая лишний раз мозг, что и нужно в большинстве случаев.
Я не сказал что Ваш метод плох, я Вас не критиковал и не пытался Вас оскорбить.
Цель моего комментария — дать ссылку на отличный сервис, более комплексно решающий данную проблему.
Тоже пользуется fakeroot'ом, об этом даже задумываться не надо.
Умеет готовить скрипт сборки для загрузки в AUR (репозиторий пользовательских пакетов Arch'а) и сама доложит в архив всё, что надо (если есть какие-то сторонние патчи, которые нельзя стянуть с интернета во время установки).
Если есть голова на плечах и конкретная задача, то использовать make install можно.
Если ты чайник и хочется толики экстрима, то лучше собирать пакет.
и чтобы стояла конкретная версия не соответствующая последней.В дебиане есть такая штука как dpkg --set-selections, с помощью которой можно запретить обновлять пакет без явного на то указания. В других дистрах есть аналоги. Не надо делать грязных хаков в виде make install, курите мануалы по своему пакетному менеджеру.
Вам не кажется это, мягко говоря, странным подходом?
— Установить пакет нужной версии.
— Запретить пакетному менеджеру обновлять этот пакет.
— Когда понадобиться свежая версия пакета, снять запрет и обновиться.
Грязный хак — это использовать ручную установку в обход менеджера пакетов, точно так же, как использовать недокументированные функции в обход открытого API.
Нужно протестировать новую версию ПО, которого нет в репах, но уже есть у разработчика.
Варианты:
1. Можно поставить его в /opt обычным make install двумя командами и одной удалить.
2. Можно выпендриться с созданием пакета и ставить все в живую систему при этом не имея гарантии что ПО не испоганит существующие настройки. Это займет 3 команды на установку в RPM-подобных и 6-7 в deb, плюс риск порчи данных.
2-й вариант получается пакетный менеджер ради пакетного менеджера.
Т.к. его функции только создадут дополнительные шаги.
Соответственно вопрос: Зачем?
Или у вас только «сферические кони в вакууме»?
configure --prefix = /usr/local после этих действий будет Makefaile,
где описан процесс сборки и установки и деинсталляции,
так что потом можно легко сделать make uninstall.
А ставить в бинарный дистр в /bin /usr/bin, самосбор — дурной тон :) получается действительно каша.
И все таки рекомендую почитать доку по LFS и GNU configure and build system.
Там еще очень много интересного :)
где описан процесс сборки и установки и деинсталляцииОтлично, его надо хранить в сухом и недоступном для детей месте до того момента, когда понадобится обновиться?
Если хотите свои пакет часто обновлять, то рекомендуют сделать ebuild, rpm, deb, и тд
Если все-таки нет желания разбираться с устройством *nix-ов,
то могу предложить такой путь:
распаковывайте установленную версию
confugure --prefix=/usr/local; make; make uninstall
распаковывайте новую
confugure --prefix=/usr/local; make; make install
Если одна зависит от другой, то на это случай и нужны пакеты в дистрибутивах,
там описаны требования (другие пакеты) необходимые устанавливаемой программе.
При использовании make install'a даже с префиксом в /usr/local от этой проблемы убежать достаточно сложно и ресурсозатратно.
В конце концов лучше день потерять, за то потом за 5 минут долететь, чем сейчас за полсекунды отделаться, а потом неизвестно сколько расхлёбывать.
Можно иметь собранными и установленными несколько разных версий одной и той же программы.
Никто не спорит с тем что пакетный менеджер это круто.
Вызывают удивления части статьи про то, что якобы процесс установки контролировать практически невозможно. Не говоря уже о том, что за 10 лет работы с юникс системами я не видел ни одного исходника где не было бы правила make uninistal или make clean или make distclean
Работа с исходниками действительно требует чуть больших знаний чем работа с пакетным менеджером. И, конечно, больше времени. Но, настаиваю, большинство проблем описанных в статье вызваны неумением пользоваться инструментом. А не кривизной самого инструмента.
Вызывают удивления части статьи про то, что якобы процесс установки контролировать практически невозможно.Покажите место, где написано, что «процесс невозможно контролировать». И не стоит забывать, что Makefile не обязательно должен быть сгенерирован automake+autoconf, особенно если код не на C/C++. Внутри может вообще использоваться другая система сборки, а Makefile сделан для унификации внешнего интерфейса.
Но, настаиваю, большинство проблем описанных в статье вызваны неумением пользоваться инструментом.Суть в том, что про эти проблемы надо знать. О них ведь нигде не пишут, а предлагают тупо скопипастить ./configure && make && make install, что и делает читающий статью, ведь она на хабре и ей понаставлено так много плюсов. И вот что делать человеку, когда проблемы таки вылезают? А вот если в статье вместо make install напишут checkinstall, это само по себе избавит от них воспользовавшегося инструкцией.
Можно иметь собранными и установленными несколько разных версий одной и той же программы.
Вам никто не мешает собрать пакеты для разных версий одной и той же программы и одновременно их установить и наслаждаться всеми прелестями пакетного менеджмента.
Я говорю о том, что изанчальный посыл статьи — нужно использовать пакетный менеджер потому что
Так вот, если вы делали установку напрямую через make install, то нормально удалить или обновить софтину вы, скорее всего, не сможете.
или
После этого процесса совершенно никакой информации о том, что и куда ставилось, получить в удобоваримом виде невозможно. Иногда, конечно, Makefile поддерживает действие uninstall, но это встречается не так часто, да и не факт, что корректно работает. Помимо этого хранить для деинсталяции распакованное дерево исходников и правил сборки как-то странно.
НЕВЕРНЫЙ. И говорит лишь о том, что у автора нет достаточного опыта в работе с исходниками.
И говорит лишь о том, что у автора нет достаточного опыта в работе с исходниками.Я рад, что вы живёте в идеальном мире, но у автора есть опыт работы с Makefile, в которых не было правила uninstall и с фактом затирания конфигурационных файл. И то и другое весьма неприятно и вылезает далеко не сразу.
У каждого пакета могут быть свои уникальные правила, по которым его необходимо обновлять, и если вы считаете что checkinstall — панацея, то вы ошибаетесь.
Пока не видел ни одной нужной мне программы с отсутствующим make uninstall.Да, давайте займём позицию страуса.
вы не сказали как будет вести себя checkinstall если вдруг какой-нибудь конфигурационный файл изменитсяОно включает всё, что в /etc в список конфигов, после чего вопрос о замене файлов будет задавать пакетный менеджер.
и если вы считаете что checkinstall — панацеяПанецея — это такая штука, которой не может быть в общем случае по определению. checkinstall же позволяет отработать 99% стучаев софта, ставящегося по ./configure && make && make install.
К читателям: почитайте «Введение в POSIX'ивизм.»© Алексей Федорчук, 2005 — там эта тема правильно и красиво расписана в Главе 10.
судя по всему вы о опции --prefix не читали и о назначении директорий /opt и /usr/local понятия не имеете.А вы заметку по-диагонали читали, видимо. Хотя, можете плодить кучу неподконтрольного пакетному менеджеру хлама где угодно, это ваше право.
Что мешает пользователю с прямой рукой удалять все файлы через make uninstall, сохранив перед этим конфиги?
Алсо, не каждый пользователь знает как собирать пакеты, а если мейнтейнер уснул на несколько лет и забил на пакет X, то ему думаю быстрее всего скачать сорсы с сайта и сделать make install.
А допустим если ты разрабатываешь какой-то программный продукт.Если я разрабатываю продукт, то я чётко знаю, что, куда и зачем он ставит. Чего не могу сказать о свежескачанных сырцах из интернета.
быстрее всего скачать сорсы с сайта и сделать make installПри написании checkinstall вместо make install количество нажатых клавиш не меняется, а пакетный менеджер узнаёт о софтине и она переходит под его управление.
Раз: директория /opt предназначена как раз для самосборных сложных програм, тоесть создаем там, например, /opt/kde и делаем make install --prefix=/opt/kde, после чего получаем собранный, работоспособный, большой пакет, который в случае чего можно без проблем удалить.
Два: /usr/local — аналог / для маленького самосбора, который можно без проблем повычищать руками из поддиректорий.
Три: предложенный вами вариант неплох, но он не всегда удобен и работает далеко не везде.
Спасибо за минус в карму. ПодавитесьЭм. Вы меня с кем-то спутали. Я минусов в карму за мнение, отличающееся от моего никогда не ставлю. Как писал Вольтер, «мне ненавистны ваши убеждения, но я готов отдать жизнь за ваше право их высказывать».
если он не понимает как работает make и что такое Makefile — это его проблемы.Это не повод создавать проблемы тем, кому адресуется статья про установку %softwarename% на %distroname%.
К тому-же ваши «советы» применимы только к deb-based бистрибутивам.Они применимы ко всему, что использует бинарные пакеты.
Раз: директория /opt предназначена как раз для самосборных сложных програм, тоесть создаем там, например, /opt/kde и делаем make install --prefix=/opt/kde, после чего получаем собранный, работоспособный, большой пакет, который в случае чего можно без проблем удалить.Я уже, кажется, писал, что софтина может ожидать того, что там, куда её ставят, её увидит кто-то ещё. Даже пример с /usr/share/xsessions привёл. Иногда установщики могут что-то в /etc/modprobe.d добавлять.
Два: /usr/local — аналог / для маленького самосбора, который можно без проблем повычищать руками из поддиректорий.Вы сейчас призываете к тому, что противоречит самой идее, ради которой создавались ЭВМ — автоматизировать всё то, что можно автоматизировать.
./configure --prefix=/home/%username%/
make install
Понятно, что голый «make install» бесконтрольно замусоривает систему. Об этом просто нужно знать (ну, обучать там), а если всех расстреливать за незнание — люди быстро кончатся :)
Кому понятно? Почему замусоривает? Чем замусоривает? Статья с комментами — куча каких-то невнятных обобщений.
Есть софт с хреново прописанными скриптами сборки и целями установки. Пользуюсь парой программ, собираемых CMake, у которых нет целей uninstall в принципе. Меня лично это не особо колышет, потоиу что они а) в /opt и б) я давным-давно выяснил, что и куда они пишут. Остальные почти всего устанавливаются и удаляются корректно.
Половина софта для музыкантов сейчас собирается вообще через waf. Чекинсталл уже научился его питонский скрипт читать?
почти всегда :)
Я мог-бы запустить «make uninstall», но в 99% случаев исходники вместе со всеми временными файлами удаляются после сборки. Так что корректно де-инсталлировать уже ничего нельзя.
Поэтому, как автор статьи и написал, нужно ставить софт из стандартных репозиториев, которые отслеживают зависимости и корректно обновляют пакеты.
Или, если стандартный репозиторий не подходит, ставить в выделенный каталог в /opt, чтобы удалять простым одним движением — точно как вы написали :-)
Так что статья вполне имеет право на жизнь, в качестве ликбеза.
Зачем? :)
> Так что корректно де-инсталлировать уже ничего нельзя.
Это называется ССЗБ :)
> Поэтому, как автор статьи и написал, нужно ставить софт из стандартных репозиториев, которые отслеживают зависимости и корректно обновляют пакеты.
В идеале — да. Но на практике это не всегда возможно.
> Так что статья вполне имеет право на жизнь, в качестве ликбеза.
Это само собой. Мне просто совершенно непонятны эмоции, которыми это сопровождается :)
> Зачем? :)
Так они дикое место занимают, как правило. К тому же это нелогично — оставлять кучу временных файлов и исходников ради отдного скрипта деинсталляции.
>> Так что корректно де-инсталлировать уже ничего нельзя.
> Это называется ССЗБ :)
ИМХО, это недостаток дизайна инструмента сборки. Я бы даже сказал, что это из области usability. Но все эти инструменты были созданы очень давно, когда требования очень сильно отличались от нынешних. Вообще automake сильно отстал от жизни. Каждый раз об этом задумываюсь, когда запускаю ./configure в Apache и час или больше жду его завершения на каком-нибудь AIX-e или HP-UX-e, потому-что он тупо повторяет одни и те же тесты для каждой из библиотек.
Мы говорим о десктопе или о сервере?
> К тому же это нелогично — оставлять кучу временных файлов…
От make clean ещё никто не умирал :)
> ИМХО, это недостаток дизайна инструмента сборки. Я бы даже сказал, что это из области usability.
А вот здесь соглашусь. Я бы хотел видеть более простые и надёжные инструменты сборки.
mkdir DEBIAN
find etc|sed "s/^/\//"|DEBIAN/conffiles
Эм, а почему debian заглавными буквами? Да и второе «|», пожалуй, стоит заменить на «>»;.
Эм, а почему debian заглавными буквами?
-b, --build directory [archive|directory]
Creates a debian archive from the filesystem tree stored in directory. directory must have a DEBIAN subdirectory, which contains the control information
files such as the control file itself. This directory will not appear in the binary package's filesystem archive, but instead the files in it will be put
Да и фряхой, как рабочей машинкой пользуются единицы, так что увязнуть в софте — почти не реально, ИМХО.
Все делается само в 1 команду (первые 2 делаются лишь в самый первый раз, так что не в счет). Например с нвидиа это выглядит так:
aptitude install module-assistant
m-a prepare
m-a a-i nvidia-kernel
Правда сейчас понабежит толпа народу, у которых еще за неделю до релиза драйвер уже считается морально устаревшим и ждать, пока он появится в дистрибутиве совсем нету времени. Но тут уж каждый сам выбирает, шашечки или ехать (:
Менеджеры пакетов зачастую не готовы предоставить последние версии многих продуктов. Размеры проблемы зависят от дистрибутива, тем не менее, проблема присутствует даже в убунте с федорой.
И да, как правило, каждому хотя бы один раз требуется что-то из этого 1%.
Пусть ставят Gentoo, размаскировывают ~x86/~amd64 и радуются :)
А вообще, непонятно такое желание юзеров, разве недостаточно того, что пакеты достаточно свежие, хоть и не самые свежие?
что одно — тайная магия в форме иероглифов, что другое
Если и используете какие-то английские слова (что безумно позорно для русского человека), то постарайтесь их объяснить (а лучше вообще заменить) в самом начале публикации.
Что такое «make» можно нагуглить за полминуты. Первая ссылка.
Если нужно на одну и туже машину поставить php двух версий, то ставьте ещё один апач (или какой-либо другой сервер) и цепляйте к нему php 5.2.
Удобно бывает.
или это не приложение?
У самого на работе предостаточно всякой всячины из тарболов (модули ядра для «нестандартных» железяк), кое-какие библиотеки…
sudo auto-apt update && auto-apt -y run ./configure
Команда auto-apt автоматом будет доставлять пакеты с необходимыми файлами, всякие там заголовочные файлы .h подробнее 5.3 Установка пакетов «по запросу»
Этот шаг позволит автоматически удовлетворить зависимости компилируемой программы и меньше будете пытать людей на форумах, типа чего надобно программе на слове stdio.h NOT FOUND
потом
checkinstall -D
Этот шаг позволит автоматически удовлетворить зависимости компилируемой программы и меньше будете пытать людей на форумах, типа чего надобно программе на слове stdio.h NOTЯ обычно иду на packages.ubuntu.com и ищу там. Как будет разруливать проблемы с повторяющимися именами заголовочных файлов сия утилита — не знаю, вручную как-то надёжнее.
Вызывая пояснительную бригаду! Устанавливаю через checkinstall,
у меня спрашивают
"Some of the files created by the installation are inside the home directory: /home
You probably don't want them to be included in the package.
Вы хотите посмотреть их список? [n]: n
Исключить их из пакета? (ответить ДА-хорошая идея) [n]: "
Собственно вопрос в том, что значит [n] — рекомендуется нажать n? Почему тогда в скобках просят y? Или это значит "Да, исключить"?
Вот за описанные проблемы-то я и недолюбливаю линуксы. 20 лет с ними работаю и 20 недолюбливаю.
Когда нормального способа собрать программу со своими ключами не существует и нужно ставить программы из репозитория через пакетный менеджер, которые собирал неизвестно кто и как. Или засорять систему через make install.
То ли дело FreeBSD с ее, не побоюсь этого слова, гениальной системой портов. Как надо - так и собрал, и удалил если надо, и когда собралось - в базу пакетного менеджера прописалось.
В Gentoo с ее портаджами похоже сделано, но менее удобно и вообще через-одно-местно.
А почему checkinstall так себе выход?
Тем, что за зависимостями все равно нужно следить самому. И тем, что в freebsd-шных портах каждый порт содержит набор патчей, которые нужно наложить на исходники, чтобы для имеющейся версии ОС все правильно собралось, а в случае checkinstall за этим опять же нужно следить самому.
Но лучше, чем ничего, конечно.
Источник утвержает
"Система управления пакетами во FreeBSD очень далека от совершенства."
Было бы любопытно услышать ваше мнение.
Также в продолжение темы статьи вообще хочется привести источник, который объясняет, почему развитие утилиты checkinstall завершилось в 2016. У меня вопрос к уважаемым хабравчанам. А что мне использовать вместо checkinstall при виде make install в readme.txt очередного софта? Разумеется я заинтересован как можно быстрее собрать и уже запустить программу.
«Правильный» процесс с предварительным созданием пакета исходного кода выходит за рамки данной заметки, а потому описан не будет, но для ваших целей оно обычно и не нужно.
А будет по этой теме заметка? Лично я в таком ликбезе очень нуждаюсь, т.к. недавно что грохнул винду, и установил Astra Linux, а знаний крайне не хватает и от IT далёк.
Хочется взять и расстрелять, или ликбез о том, почему не стоит использовать make install