Pull to refresh

Comments 185

Судя по заголовку, действительно наболело)
И судя по тегам тоже :)
судя по количеству людей, которые добавили в избранное, некоторые знания на поверхностном уровне, даешь ликбез в народ
я добавил в избранное, потому что комменты в таких статьях, не менее интересны чем сама статья и когда будет нужно, я смогу поднять исчерпывающие сведения по этому вопросу, тупо проглядев комменты и открыв ссылки
deb и checkinstall это хорошо. Вопрос. Подскажите теперь аналогичную тулзу для ArchLinux-а и CentOS-и
Так в центосе, емнип, тоже ж чекинсталл есть, который весьма успешно собирает rpm'ки.
checkinstall и rpm умеет, в арче — писать (или править любой готовый) pkgbuild.
RPM-ки checkinstall собирать умеет, так что ищите его в репах. А вот насчёт особого, принципиального нового формата пакетов арча ничего сказать не могу.
Или yaourt который проверит есть ли готовый PKGBUILD для пакетa в aur.
to kekekeks Новый формат пакетов а арче xz? Если да, то внутри тоже самое что и было просто более сильно пожатое.
Это такой намёк на то, что он отличается от остальных популярных бинарных дистров, использующих rpm/deb.
Я к тому, что, быть может, есть тулзы, которые автоматом генерят PKGBUILD?
На основе чего? PKGBUILD — shell-script c минимальным описанием пакета, я с трудом представляю, что в нём можно генерить.
Я знаю, что такое PKGBUILD. Вот только checkinstall вообще генерит пакет с нуля. Вот я хочу чтоб нечто генерило PKGBUILD (хотя бы базовый) с нуля.
checkinstall генерирует пакет посредством перехвата make install.
А PKGBUILD — это инструкция по сборке пакета. Поэтому сгенерировать его нельзя.
Согласен с вами на все 110%.
Проще чем сборка пакета в арче из PKGBUILD — при помощи makepkg вообще не в одном дистрибутиве не видел. Простой bash-скрипт поэтапной сборки пакета — начисто лишенный обращения к каким либо макросам, из всего что нужно знать — это названия переменных с которыми работает makepkg(архитектура, корневой каталог, каталог с исходниками, каталог с файлами пакета и т.д.). Потому: если, даже в общих чертах, знаешь bash — научиться писать PKGBUILD-ы дело 30-ти минут, тем более готовых «шпаргалок» огромное количество в ABS и AUR.
пс:
Тоже по сути наболело: раньше часто приходилось писать spec-файлы для «синтеза» rpm пакетов. Так вот писать PKGBUILD-ы после spec-ов: все равно что есть руками после использования кучи бесполезных и неудобных, но специализированных, костылей для каждого блюда.
checkinstall есть в репо rpmforge. Подключайте и пользуйтесь ;)
Для ArchLinux checkinstall есть в community репозитории. (во всяком случае, для 64-bit'ной

community/checkinstall 1.6.2-1
Сначала Москва была Default City, потом Linux почему-то стал Default OS, а теперь стали забывать и о том, что кроме «любимого» ещё и другие дистрибутивы существуют :)
checkinstall покрывает все deb и rpm-based дистры, которых подавляющее большинство. Гентушники и сами разберутся, генту без долгого курения мануалов о том, как всё работает, не ставят. Остаётся только арч и совсем уж малоизвестные дистры, про которые можно даже не вспоминать.
Посмотрите в сторону pacinstall/wocka — аналоги checkinstall для Arch.
Wocka мертва с 2007 года, pacinstall как зависимость требует installwatch, которого уже ни в репозиториях, ни в АУРе. Есть ещё какие-нибудь альтернативы?
Да, видно, не только я переживаю за сотни захламленных систем этим мейк инсталлом. (:

зы. Какой у вас сложный и интересный способ сборки DEBIAN'овских пакетов. (:
Я всю жизнь собирал через dh_make и dpkg-buildpackage -rfakeroot. На мой взгляд, гораздо удобнее, разве что иногда приходится повозиться с некоторым софтом, потому что часть файлов забывает включаться в пакет.
dh_make генерирует довольно таки толстый debian/rules, который может на определённом этапе выдать ошибку или же вообще собрать нерабочий пакет, я, к сожалению, уже с этим не раз уже сталкивался. Описание же подводных камней выходит за рамки статьи. Так что описан 100%-рабочий способ с минимумом телодвижений.
У вас слишком старый dh_make. Теперешние debian/rules состоят зачастую из 4 строк, одна из который — шебанг, вторая пустая, третья из двух символов, а чётвёртая длиной меньше 10.
Ага, а разворачивается это в ту же самую простыню команд на 2 страницы.
Оно не разворачивается. Просто всё нужное запускает сам dh. Да и ломаться-то там нечему. Обычные пакеты, собирающиеся по ./configure && make соберутся там с такой же лёгкостью.
Были случаи, когда dh_shlibdeps отваливался.
Поподробнее напишите про ваш метод плиз.
Спасибо.
dh_make — это такая штука, которая позволяет быстро получить заготовку пакета исходного кода, которой достаточно в 80% случаев. Ниже ссылку давали на дебиановкий мануал по сборке пакетов, если интересно узнать, как это идеологически правильно делается, можете ознакомиться.
В мемориз! Отличная статья)

Давно в курсе что make install зло — но вот как-то руки не доходили до сборки пакетов собственноручно, хотя оказываеться все гораздо проще чем я предполагал.
Вообще, советы ваши несколько неправильные: пакеты из исходников сейчас собираются через dh_make -> debchange -> debuild -> debrelease с минимальным напряжением

www.debian.org/doc/manuals/maint-guide/index.en.html
Отличный план, Жозе! А теперь вспоминаем, зачем обычно собирают из исходников. Правильно, чтобы изменить что-то в конфигурации сборки. Вам напомнить, какой debian/rules генерит dh_make?
export DH_OPTIONS
%:
dh $@
Вы мне предлагаете в статье объяснять, где что и как править, чтобы добавить туда свои опции?
Суть в том, что ничего править не нужно, Хуан!

Тем более файл debian/rules

На этапа dh_auto_build автоматически вызовется make -f Makefile в родительской директории с уже правильно установленной переменной окружения DISTDIR и все файлы соберуться в нужной директории и будут упаковы
Ладно, не будем спорить из-за того, какие именно 3.5 команды надо копипастить, тем более, что у вы описываете идеологически правильный способ. Для статьи же была выбрана методика, задействующая минимум дополнительных сущностей.
Как раз таки checkinstall умеет создавать rpm пакеты, хотя по оф сату только для слаки, но думаю разница не столько большая, чтобы он в CentOs не установился
Откройте для себя силу OpenSuSE Build Service (https://build.opensuse.org/), собирает RPM и DEB пакеты, имеет уже кучу собранных.
Нужно только немного напрячься и почитать man`ы по SPEC файлам ;)
Откройте для себя силу OpenSuSE Build Service (https://build.opensuse.org/), собирает RPM и DEB пакеты, имеет уже кучу собранных.
Слушайте, у меня 3 ppa-шки на ланчпаде, не надо мне рассказывать, как правильно писать сценарии сборки пакетов. В статье предложен упрощённый способ, как это сделать быстро, имея результаты сборки из дерева исходников и не включая лишний раз мозг, что и нужно в большинстве случаев.
оО откуда столько агрессии?
Я не сказал что Ваш метод плох, я Вас не критиковал и не пытался Вас оскорбить.

Цель моего комментария — дать ссылку на отличный сервис, более комплексно решающий данную проблему.
Воспринял комментарий как наезд, извините.
А ново сгенерированные RPM конфиги не затирают?
* А ново сгенерированные RPM, конфиги не затирают?
не должны, по идее, rpm новые конфиги, при наличии в системе файла с тем же именем, переименовывает в %name%.rpmnew
В Arch'е тоже отличная штука есть: makepkg называется, грузит исходники и собирает пакет по простенькому скрипту (PKGBUILD).
Тоже пользуется fakeroot'ом, об этом даже задумываться не надо.
Умеет готовить скрипт сборки для загрузки в AUR (репозиторий пользовательских пакетов Arch'а) и сама доложит в архив всё, что надо (если есть какие-то сторонние патчи, которые нельзя стянуть с интернета во время установки).
Если бы ещё и был краткий обзор создания пакетов в разных популярных системах, было бы совсем шикарно. Но и так злободневно :)
А для MacOS X при использовании brew/fink/ports что-то подобное есть? Иногда возникает необходимость в консольных утилитах, которых нет в репозиториях
Fink является портом дебиановского менеджера пакетов. Так что собирать под него можно по инструкции из статьи.
В brew можно brew edit aria2, к примеру (подойдет что угодно, что устанавливается по make install без патчей), и поправить url, md5 и homepage. Не «само», но работы на 5 минут от силы.
А ещё можно не особенно важные сторонние программы устанавливать, пусть даже make install'ом, в домашний каталог, куда-нибудь в ~/bin (указывая его как --prefix/PREFIX вместо /usr/local). Систему не затрагивает, удаляется легко.
Мне нравятся арчевские PKGBUILD'ы. Это даже немного на checkinstall похоже, можно в package() написать make DESTDIR=$pkgdir install и все.
Бывают ситуации когда как раз нужно чтобы о ПО не знал пакетный менеджер, чтобы оно не втискивалось в существующую систему, и чтобы стояла конкретная версия не соответствующая последней.

Если есть голова на плечах и конкретная задача, то использовать make install можно.
Если ты чайник и хочется толики экстрима, то лучше собирать пакет.
и чтобы стояла конкретная версия не соответствующая последней.
В дебиане есть такая штука как dpkg --set-selections, с помощью которой можно запретить обновлять пакет без явного на то указания. В других дистрах есть аналоги. Не надо делать грязных хаков в виде make install, курите мануалы по своему пакетному менеджеру.
Т.е. вы считаете лучшим делать грязные хаки пакетному менеджеру, функционал которого будет только мешать в задаче?
Вам не кажется это, мягко говоря, странным подходом?
Это не грязные хаки, а вполне обычный функционал, не передёргивайте. И чем вам помешает пакетный менеджер, интересно? Объясните, что ненормального в такой последовательности действий:
— Установить пакет нужной версии.
— Запретить пакетному менеджеру обновлять этот пакет.
— Когда понадобиться свежая версия пакета, снять запрет и обновиться.

Грязный хак — это использовать ручную установку в обход менеджера пакетов, точно так же, как использовать недокументированные функции в обход открытого API.
Пример:
Нужно протестировать новую версию ПО, которого нет в репах, но уже есть у разработчика.
Варианты:
1. Можно поставить его в /opt обычным make install двумя командами и одной удалить.
2. Можно выпендриться с созданием пакета и ставить все в живую систему при этом не имея гарантии что ПО не испоганит существующие настройки. Это займет 3 команды на установку в RPM-подобных и 6-7 в deb, плюс риск порчи данных.

2-й вариант получается пакетный менеджер ради пакетного менеджера.
Т.к. его функции только создадут дополнительные шаги.

Соответственно вопрос: Зачем?
На «потестировать» я держу отдельное чистое chroot-окружение, поверх которого перед установкой «свежатинки» монтируется временная файлуха через aufs. Быстро поднимается, нет риска порчи данных.
А что делать если нужно тестировать его в работе?
Или у вас только «сферические кони в вакууме»?
Ну а в чём проблема тестирования в изолированном окружении-то? Зачем ставить параллельно со стабильной версией и запускать вместо неё? Давно не играли в русскую рулетку?
Задачи бывают разные, если у вас каких-то не было, не значит что их не бывает.
И все-таки вопрос — зачем придумывать себе лишнюю работу?
И опять таки, зачем лишние действия если можно их обойти без каких-либо рисков?
Каким образом это решит перечисленные проблемы?
Авторы программ просят начала сделать configure, где можно указать префикс
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
Зато как классно потом установить программу X версии 5.6.7 которая конфликтует с уже установленной подобным способом программой Y версии 3.2.1, а потом героически несколько суток разбираться почему же ничего не работает.
Что значит конфликтует?
Если одна зависит от другой, то на это случай и нужны пакеты в дистрибутивах,
там описаны требования (другие пакеты) необходимые устанавливаемой программе.
Простейший пример: для корректной работы пакет X, требуется пакет Y с версией старше 3.5.1, а у вас только 3.2.1.
При использовании make install'a даже с префиксом в /usr/local от этой проблемы убежать достаточно сложно и ресурсозатратно.
В конце концов лучше день потерять, за то потом за 5 минут долететь, чем сейчас за полсекунды отделаться, а потом неизвестно сколько расхлёбывать.
для корректной работы пакет X, требуется пакет Y с версией старше 3.5.1, а у вас только 3.2.1.
Как раз на это будет ругаться configure.
Хинт:
Можно иметь собранными и установленными несколько разных версий одной и той же программы.

Никто не спорит с тем что пакетный менеджер это круто.

Вызывают удивления части статьи про то, что якобы процесс установки контролировать практически невозможно. Не говоря уже о том, что за 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 и с фактом затирания конфигурационных файл. И то и другое весьма неприятно и вылезает далеко не сразу.
Пожалуйста, приведите пример Makefile без uninstall
Первое, что попалось под руку — THC-HYDRA. Самое забавное, что для gtk-шного гуя к ней правило uninstall есть.
Тээээкс. Либа polarssl так же поставляется с Makefile без этого правила. Продолжать? Давайте, скажите, что у меня неправильный софт с неправильными Makefile.
некоторые пакетные менеджеры (portage) умеют держать одновременно установленными несколько версий. К apt, это, правда, не относится: в убунте даже разные пакеты одновременно иногда невозможно установить
UFO just landed and posted this here
А почему тогда dropbear при установке рядом с openssh-server спокойно слушает другой порт (разумеется, предупреждая об этом, и указывая, где это можно отключить)?
UFO just landed and posted this here
Кто бы ещё сорвал покровы с пакета autotools.
этого человека зовут Чеусов, и он уже неоднократно это делал на LVEE и не только
Мне кажется, автор немного передёргивает. Просто всё надо делать с умом.
картинка с котятами просится быть напечатанной и повешенной над столом
Почему сразу DEB? Можно было и про RPМ написать…
Пока не видел ни одной нужной мне программы с отсутствующим make uninstall. Да и раз на то пошло, вы не сказали как будет вести себя checkinstall если вдруг какой-нибудь конфигурационный файл изменится или если программа создаёт какие-то свои базы данных с каким-нибудь кэшем, формат которых может меняться от версии к версии.
У каждого пакета могут быть свои уникальные правила, по которым его необходимо обновлять, и если вы считаете что checkinstall — панацея, то вы ошибаетесь.
Пока не видел ни одной нужной мне программы с отсутствующим make uninstall.
Да, давайте займём позицию страуса.
вы не сказали как будет вести себя checkinstall если вдруг какой-нибудь конфигурационный файл изменится
Оно включает всё, что в /etc в список конфигов, после чего вопрос о замене файлов будет задавать пакетный менеджер.
и если вы считаете что checkinstall — панацея
Панецея — это такая штука, которой не может быть в общем случае по определению. checkinstall же позволяет отработать 99% стучаев софта, ставящегося по ./configure && make && make install.
вам везло. Я встречал. И встречал такие, у которых установка DESTDIR не помогает. Приходится патчить мейкфайлы, исходники и т. п.
К ТС: судя по всему вы о опции --prefix не читали и о назначении директорий /opt и /usr/local понятия не имеете. Лучше сначала разберитесь толково в архитектуре POSIX-совместимых ОС, а потом уже советуйте.
К читателям: почитайте «Введение в POSIX'ивизм.»© Алексей Федорчук, 2005 — там эта тема правильно и красиво расписана в Главе 10.
судя по всему вы о опции --prefix не читали и о назначении директорий /opt и /usr/local понятия не имеете.
А вы заметку по-диагонали читали, видимо. Хотя, можете плодить кучу неподконтрольного пакетному менеджеру хлама где угодно, это ваше право.
А допустим если ты разрабатываешь какой-то программный продукт. По твоему мнению, надо собирать каждый билд в пакетики а потом их уже тестировать на машине?

Что мешает пользователю с прямой рукой удалять все файлы через make uninstall, сохранив перед этим конфиги?

Алсо, не каждый пользователь знает как собирать пакеты, а если мейнтейнер уснул на несколько лет и забил на пакет X, то ему думаю быстрее всего скачать сорсы с сайта и сделать make install.
А допустим если ты разрабатываешь какой-то программный продукт.
Если я разрабатываю продукт, то я чётко знаю, что, куда и зачем он ставит. Чего не могу сказать о свежескачанных сырцах из интернета.
быстрее всего скачать сорсы с сайта и сделать make install
При написании checkinstall вместо make install количество нажатых клавиш не меняется, а пакетный менеджер узнаёт о софтине и она переходит под его управление.
Спасибо за минус в карму. Подавитесь. Толковую литературу читать вы тоже не собираетесь — отлично. А с какого перепугу вы решили, что то, что не контролирует пакетный менеджер — хлам? Каждый пользователь сам в ответе за свои действия, если он не понимает как работает make и что такое Makefile — это его проблемы. К тому-же ваши «советы» применимы только к deb-based бистрибутивам. То есть вы даете «подоконные» советы — вы рассказываете готовый рецепт о том как нужно делать в данном конкретном случае, применимом к нескольким дистрибутивам, вместо того, чтобы познакомить новичков с основами и прояснить им суть сборки пакетов из исходников.
Раз: директория /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 — аналог / для маленького самосбора, который можно без проблем повычищать руками из поддиректорий.
Вы сейчас призываете к тому, что противоречит самой идее, ради которой создавались ЭВМ — автоматизировать всё то, что можно автоматизировать.

Я понял вашу точку зрения. Я просто любитель более общего подхода, когда люди сначала изучают основы, а в частностях после этого разобраться не проблема. Ни в коем случае не против автоматизации, просто я считаю, что перед тем как автоматизировать нужно знать как это делается руками, как это устроено и как это вообще работает. Простите за наезд.
[sarcasm]Судомейкинсталлил, судомейкинсталлю, и буду судомейкинсталлить. Не переубедите...[/sarcasm]
в чем принципиальная разница c aptitude install?
А что мешает устанавливать с помощью

./configure --prefix=/home/%username%/
make install
Да, на самом деле — я, к примеру, все, что не устанавливается автоматически apt-get-ом, спокойно ставлю в /opt/product_name-version/ и все. Потом это сносится простым удалением каталога.

Понятно, что голый «make install» бесконтрольно замусоривает систему. Об этом просто нужно знать (ну, обучать там), а если всех расстреливать за незнание — люди быстро кончатся :)
Я тоже так когда-то делал. Перестал после того как убил 4 часа на выяснение того, почему wimaxd отказывается нормально работать. Выяснилось, что install кладёт файлик в /etc/modprobe.d, который из-за установки в префикс куда надо не попал.
> Понятно, что голый «make install» бесконтрольно замусоривает систему.

Кому понятно? Почему замусоривает? Чем замусоривает? Статья с комментами — куча каких-то невнятных обобщений.

Есть софт с хреново прописанными скриптами сборки и целями установки. Пользуюсь парой программ, собираемых CMake, у которых нет целей uninstall в принципе. Меня лично это не особо колышет, потоиу что они а) в /opt и б) я давным-давно выяснил, что и куда они пишут. Остальные почти всего устанавливаются и удаляются корректно.

Половина софта для музыкантов сейчас собирается вообще через waf. Чекинсталл уже научился его питонский скрипт читать?
> почти всего

почти всегда :)
Например, я собираю программу из исходников, запускаю дефолтный «make install», и он записывает часть файлов в /etc, часть в /usr/local/lib, часть в /var, часть еще фиг знает куда.

Я мог-бы запустить «make uninstall», но в 99% случаев исходники вместе со всеми временными файлами удаляются после сборки. Так что корректно де-инсталлировать уже ничего нельзя.

Поэтому, как автор статьи и написал, нужно ставить софт из стандартных репозиториев, которые отслеживают зависимости и корректно обновляют пакеты.
Или, если стандартный репозиторий не подходит, ставить в выделенный каталог в /opt, чтобы удалять простым одним движением — точно как вы написали :-)

Так что статья вполне имеет право на жизнь, в качестве ликбеза.
> но в 99% случаев исходники вместе со всеми временными файлами удаляются после сборки

Зачем? :)

> Так что корректно де-инсталлировать уже ничего нельзя.

Это называется ССЗБ :)

> Поэтому, как автор статьи и написал, нужно ставить софт из стандартных репозиториев, которые отслеживают зависимости и корректно обновляют пакеты.

В идеале — да. Но на практике это не всегда возможно.

> Так что статья вполне имеет право на жизнь, в качестве ликбеза.

Это само собой. Мне просто совершенно непонятны эмоции, которыми это сопровождается :)
>> но в 99% случаев исходники вместе со всеми временными файлами удаляются после сборки

> Зачем? :)

Так они дикое место занимают, как правило. К тому же это нелогично — оставлять кучу временных файлов и исходников ради отдного скрипта деинсталляции.

>> Так что корректно де-инсталлировать уже ничего нельзя.

> Это называется ССЗБ :)

ИМХО, это недостаток дизайна инструмента сборки. Я бы даже сказал, что это из области usability. Но все эти инструменты были созданы очень давно, когда требования очень сильно отличались от нынешних. Вообще automake сильно отстал от жизни. Каждый раз об этом задумываюсь, когда запускаю ./configure в Apache и час или больше жду его завершения на каком-нибудь AIX-e или HP-UX-e, потому-что он тупо повторяет одни и те же тесты для каждой из библиотек.
> Так они дикое место занимают, как правило.

Мы говорим о десктопе или о сервере?

> К тому же это нелогично — оставлять кучу временных файлов…

От make clean ещё никто не умирал :)

> ИМХО, это недостаток дизайна инструмента сборки. Я бы даже сказал, что это из области usability.

А вот здесь соглашусь. Я бы хотел видеть более простые и надёжные инструменты сборки.
mkdir DEBIAN
find etc|sed "s/^/\//"|DEBIAN/conffiles


Эм, а почему debian заглавными буквами? Да и второе «|», пожалуй, стоит заменить на «&gt»;.
Эм, а почему 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
Спасибо. Для тех, кто также как и я удивился, поясню: в debian/ лежат source package control files, а в DEBIAN/ — binary package control files.
Точнее в «debian/» лежат ресурсы для файлов
а в в «DEBIAN/» лежат бинарные файлы
Эм. А чем это отличается от того, что написано выше?
Тем, что BVN2 под какими-то веществами судя по тому, что он в треде пишет.
О чём вздохнули то? У нас portupgrade один раз собирается и особых проблем при обновлении нет :)
Да и фряхой, как рабочей машинкой пользуются единицы, так что увязнуть в софте — почти не реально, ИМХО.
Ну, наверное, имелось в виду, что многие пользователи FreeBSD ставят софт примерно так:

cd /usr/ports/category/portname
make config
make install clean

Так аутентичней, что ли.

Ну так вот, я при прочтении заголовка немного напрягся. :)
И ещё драйверы на видео ставят из *.run файлов, скачанных с официальных сайтов производителей… (((
Так с драйверами, по крайней мере в дебианах, все совсем шоколадно и даже что-то качать, а потом еще и собирать самому ничего не надо.
Все делается само в 1 команду (первые 2 делаются лишь в самый первый раз, так что не в счет). Например с нвидиа это выглядит так:
aptitude install module-assistant
m-a prepare
m-a a-i nvidia-kernel

Правда сейчас понабежит толпа народу, у которых еще за неделю до релиза драйвер уже считается морально устаревшим и ждать, пока он появится в дистрибутиве совсем нету времени. Но тут уж каждый сам выбирает, шашечки или ехать (:
Спасибо за статью, она отлично мне подойдет, чтобы отпугивать от линуха незадачливых перебежчиков, которые думают, что make install — это все, что им может потребоваться для инсталляции.
Для инсталляции перебежчику в 99% случаев достаточно написать что-то типа «sudo apt-get install super-duper-software», а то и вовсе сделать пару кликов мышкой в гуе.
хм, нет. Юзеры обычно хотят свежий, недавно вышедший софт, а не его проверенную десятилетиями и поколениями бородатых одминов версию.
Менеджеры пакетов зачастую не готовы предоставить последние версии многих продуктов. Размеры проблемы зависят от дистрибутива, тем не менее, проблема присутствует даже в убунте с федорой.
И да, как правило, каждому хотя бы один раз требуется что-то из этого 1%.
> Юзеры обычно хотят свежий, недавно вышедший софт, а не его проверенную десятилетиями и поколениями бородатых одминов версию.

Пусть ставят Gentoo, размаскировывают ~x86/~amd64 и радуются :)

А вообще, непонятно такое желание юзеров, разве недостаточно того, что пакеты достаточно свежие, хоть и не самые свежие?
В убунте всё, чего нет в основном дистре, есть в ppa-шках.
не понимаю, чем для юзеров make install отличается от checkinstall

что одно — тайная магия в форме иероглифов, что другое
Спасибо за развёрнутую статью. Но есть как минимум две проблемы. Большинство не в курсе на какие темы вы давали комментарии и что в них написано. И ещё большинство людей не в курсе что такое «make install».

Если и используете какие-то английские слова (что безумно позорно для русского человека), то постарайтесь их объяснить (а лучше вообще заменить) в самом начале публикации.
На Хабрахабре большинство людей знает что такое «make install». Это IT-ресурс все-таки.
UFO just landed and posted this here
только массовые расстрелы спасут систему от таких мейкфайлов
UFO just landed and posted this here
Эм. Если человек не знает, что такое make install, то эта статья адресована вообще не ему, так что можно спокойно проходить мимо.
Да что Вы пристали к троллю человеку. У него у самого пост с кучей каких-то непонятных предложений на английском, половина из которых начинается с SELECT. И хоть бы где объяснил, что это такое, я уж не говорю про замену. Большинство ж людей не в курсе (:
Почему desenix может писать комментарии, а срать ему в карму нельзя?
Очень интересно вы говорите от имени большинства. При том, что большинство заминусовало ваш единственный пост.

Что такое «make» можно нагуглить за полминуты. Первая ссылка.
Для юзеров-гентушников есть emerge <пакет> и emerge --unmerge <пакет>. Собирает из исходников, пользуясь общим /etc/make.conf с флагами компиляции и т.д., где можно соптимайзить софт под ваши задачи и оборудование. А если софта нету в portage, можно сделать свой ebuild. Пакеты маскируются/демаскируются по желанию.
А сборка checkinstall через make install сильно портит карму?
Очень, очень сильно портит, поскольку make install ничего не собирает и сборка с его помощью есть из области чёрной магии.

На самом деле у правила install есть в зависимостях правило, по которому производится сборка
Хм… На сервере установлен php 5.2, мне нужно установить 5.3, но 5.2 не должен быть удален! Как быть? :)
Если вам нужно ставить два языка на один и тот же сервер — то это фантазии. С таким же успехом можно пытаться тратить деньги и при чём, что бы они сохранялись.

Если нужно на одну и туже машину поставить php двух версий, то ставьте ещё один апач (или какой-либо другой сервер) и цепляйте к нему php 5.2.
Извиняюсь
— не два языка, а две ПХП'шки
— … и цепляйте к нему php 5.3
Молодой человек, большинство шаред хостингов могут вам предоставить на одним и том же сервере php 5.2 и 5.3 одновременно.

Более того, при желании сюда можно воткнуть еще и пых четвертой ветки, для особых извращений.
Выставить префиксом /opt/newphp, далее по инструкции. После чего сами разбираетесь с тем, как и куда его прописать, чтобы веб-сервер увидел.
А почему не /usr/local
ведь папка пустая же в большинстве дистрибутивов,
но в отличии от /opt/newphp/bin/ /usr/local/bin уже есть в переменной path
И какой из бинарников будет запускаться из консоли? Нет уж, мухи отдельно, котлеты отдельно.
тот, к которому пропишите полный путь :) Не поддерживаю /usr/local идею, просто мимо проходил.
В Gentoo можно использовать слоты и переключаться между версиями при необходимости.

Удобно бывает.
ставьте gentoo, там можно так сделать
А не вы ли в недавнем посте писали об этом в комментариях? :) Вспомнилось просто.
Отправите статью еще в редакцию LXF. Авторы постоянно рекомендуют устанавливать новые программы из исходников через make install. Я сам, перед тем как устанавливать пакеты из исходников, ищу на лаутчпаде.
Эти чекинсталлы, fakeroot (да и сам make install — пакет не должен сам себя устанавливать) — это костыли, которыми пытаются подпереть изначально кривую архитектуру. Каждое приложение должно находиться в своей папке, а устанавливаться/удаляться созданием симлинка в /bin.
UFO just landed and posted this here
Ага, а ещё должно быть что-то типа GAC, но для so-шек. Давайте пропатчим загрузчик с компилятором и сделаем свой, принципиально новый дистрибутив.
как же быть с приложением calc.exe? Что же оно не в своей папке?

или это не приложение?
А что мешает положить его в отдельную папку? Экономия на спичках?
UFO just landed and posted this here
Лёгким движением make install превращаем нормальный дистрибутив в Slackware. ;)
Вы либо никогда не пользовались, либо просто не разбирались в Slackware. Вы не поверите, но там есть пакетный менеджер, который позволяет потом при удалении вычистить все установленные с пакетом файлы. makepkg и написание SlackBuild-ов никто не отменял.
Вы не поверите. Но я знаю про пакетные менеджеры в Slackware. Я вам даже по секрету скажу, что их там больше, чем один. И SlackBuild'ы для сборки пакетов я тоже писал. А ещё для Slackware есть репозитории с уже собранными пакетами, а также небезысвестный slackbuilds.org/ с множеством уже готовых слакбилдов под разные версии Slackware. Обвинить в некомпетентности человека это самое простое, а вот увидеть шутку наверное дано не всем.
Да ладно, не серчайте. И про репы и про остальные пакетные менеджеры я тоже знаю. Слака была моим первым дистром. На slackbuilds.org даже мной присланные слакбилды когда-то были. И про то что это была шутка я тоже знаю. Но эту шутку лично я считаю глупой. Я просто не ожидал что такую вот «шутку» может выдать человек, который, что называется, «в теме».
Ну есть же распространённое мнение о том, что файлопомойка в слаке начинается с /
Слака тоже была моим первым дистрибутивом, на ней в принципе и учился. А шутка направлена на тех кто «не осилил» слаку. Самоирония практически. =)
Слова, конечно, очевидные. Но, к сожалению, не всегда получается обойтись только менеджером пакетов, а собирать из тарбола пакет для своего дистрибутива — задача довольно муторная.
У самого на работе предостаточно всякой всячины из тарболов (модули ядра для «нестандартных» железяк), кое-какие библиотеки…
deb-пакет по инструкции в статье собирается из дерева файлов примерно за полторы минуты, включая копирование шаблона, правку полей описания и саму установку. Арчевские пакеты, судя по комментариям, и того быстрее. Не надо оправдывать свою лень, а?
Арч у меня дома, там у меня пока чистота и порядок (в aur достаточно много необходимого, а редкое железо я дома не держу). На работе же мандрива и собирать rpm'ы просто лень.
я еще бы посоветовал бы так сначала
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 и ищу там. Как будет разруливать проблемы с повторяющимися именами заголовочных файлов сия утилита — не знаю, вручную как-то надёжнее.
за auto-apt большое спасибо. не знал.
А почему в статье говорится только про checkinstall и сборку deb-пакета, и ВООБЩЕ никак не упоминается, что это не единственные существующие в мире форматы пакетов и способы установки софта?

Вызывая пояснительную бригаду! Устанавливаю через 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? Или это значит "Да, исключить"?

UFO just landed and posted this here

Вот за описанные проблемы-то я и недолюбливаю линуксы. 20 лет с ними работаю и 20 недолюбливаю.

Когда нормального способа собрать программу со своими ключами не существует и нужно ставить программы из репозитория через пакетный менеджер, которые собирал неизвестно кто и как. Или засорять систему через make install.

То ли дело FreeBSD с ее, не побоюсь этого слова, гениальной системой портов. Как надо - так и собрал, и удалил если надо, и когда собралось - в базу пакетного менеджера прописалось.

В Gentoo с ее портаджами похоже сделано, но менее удобно и вообще через-одно-местно.

Тем, что за зависимостями все равно нужно следить самому. И тем, что в freebsd-шных портах каждый порт содержит набор патчей, которые нужно наложить на исходники, чтобы для имеющейся версии ОС все правильно собралось, а в случае checkinstall за этим опять же нужно следить самому.

Но лучше, чем ничего, конечно.

Источник утвержает

"Система управления пакетами во FreeBSD очень далека от совершенства."

Было бы любопытно услышать ваше мнение.

Также в продолжение темы статьи вообще хочется привести источник, который объясняет, почему развитие утилиты checkinstall завершилось в 2016. У меня вопрос к уважаемым хабравчанам. А что мне использовать вместо checkinstall при виде make install в readme.txt очередного софта? Разумеется я заинтересован как можно быстрее собрать и уже запустить программу.

«Правильный» процесс с предварительным созданием пакета исходного кода выходит за рамки данной заметки, а потому описан не будет, но для ваших целей оно обычно и не нужно.

А будет по этой теме заметка? Лично я в таком ликбезе очень нуждаюсь, т.к. недавно что грохнул винду, и установил Astra Linux, а знаний крайне не хватает и от IT далёк.

Sign up to leave a comment.

Articles