Comments 17
В каждой статье про сборку из исходников надо рассказывать про checkinstall. Если в статье не рассказали, надо рассказывать в комментарих. Если комментарии закрыты, надо брать баллончик с краской и выходить на улицы города.
checkinstall можно запустить на последнем этапе вместо make install. Он задаст пару вопросов и соберёт и установит пакет используемого в вашем дистрибутиве формата — deb или rpm(ничего другого она не умеет, но это покрывает значительную часть распространённых дистрибутивов). Получится достаточно небрежно собранный пакет, но по крайней мере:
- он будет отображаться в списке установленных
- все установленные файлы будут под контролем пакетной системы
- пакетная система сможет правильно себя вести в случае конфликтов этих файлов с другими пакетами
Я не вижу существенных преимуществ перед, скажем, установкой в /opt/XXX. Если установить в /opt/XXX, то вот этот самый каталог можно целиком удалить, когда пакет станет не нужен.
он будет отображаться в списке установленных
ls /opt
все установленные файлы будут под контролем пакетной системы
ls /opt
пакетная система сможет правильно себя вести в случае конфликтов этих файлов с другими пакетами
Каждый пакет в отдельной папке в /opt, никаких конфликтов.
Наконец, нашёл сейчас в README checkinstall следующее:
CheckInstall currently is unable to track any file system changes made by
statically linked programs. This is being worked on and I hope to have it ready
in a couple of weeks or so. Then again, it could be a couple of months, but the
important thing is that it will be ready soon ;).
Делаю из этого вывод, что checkinstall работает путём внедрения специальных разделяемых библиотек при запуске установочных скриптов. А это весьма хрупкий способ. Он может работать, а может и не работать. Собственно, приведённый фрагмент README говорит, что он не будет работать, если установочные скрипты запускают статически собранные программы. (Интересно выяснить, насколько давно в README висит эта фраза "This is being worked on and I hope to have it ready in a couple of weeks or so" :))
Тоже вариант, но надо будет руками создавать симлинки в общих каталогах типа /usr/bin /etc/init.d /usr/lib /usr/share/man, а при удалении не забывать их оттуда убрать.
Ну и система ничего о ваших пакетах не знает. Если вы собрали руками nginx, а какой-то другой пакет от него зависит, то будет установлен второй nginx в иерархию /usr в дополнение к вашему в /opt/nginx.
Да, если у вас статически собранные make или baseutils, checkinstall не будет работать, но в распространённых debian/redhat-like дистрибутивах это не так. Это не замена нормальной сборки пакета, но лучше чем чистый make install.
Интересно выяснить, насколько давно в README висит эта фраза
В git можно использовать для расследования этого "детектива" git blame, заодно и узнаем — кто дворецкий автор.
создадим файл app-misc/hello-world/hello-world-1.0.ebuild
p.s. я знаю почему это невозможно будет еще очень долго — потому что существует очень старый legacy и исторические наслоения.
Вообще ожидал из названия будет описание как собирать пакеты — .deb, .rpm как минимум. А описана работа с исходниками — если читать README и INSTALL, то для каждой программы уже описана процедура.
Дополнил:
(UPD от 2017-02-09: в Windows программы на самом деле тоже «размазаны», скажем, по реестру, просто это не так бросается в глаза.)
.
А описана работа с исходниками — если читать README и INSTALL, то для каждой программы уже описана процедура.
Кроме того, что обычно описано в README и INSTALL, я также сообщил много базовой информации. Собственно, эта статья была изначально написана для одного знакомого, испытывающего трудности со сборкой пакетов, и он был доволен статьёй. То есть получить эту информацию из README и INSTALL напрямую он не смог. В этом и есть суть моей статьи: в одном месте сообщить много базовой инфы для тех, кто, скажем, пересел с винды, я это написал.
Под словом «пакет» я понимаю в этой статье пакет с исходными текстами, причём не пакет конкретного дистрибутива GNU/Linux, а просто пакет, исходящий от оригинальных авторов софта.
Если существует некая библиотека под названием foo, то она обычно запаковывается для дебиан в пакеты с названиями libfoo (или libfoo1, libfoo2) и libfoo-dev
Если вы установите у себя на машине libfoo и libfoo-dev, то результат будет как если бы вы сами собрали пакет foo из исходных кодов с префиксом /usr.
*не зря в каждой хорошей книге есть раздел «Терминология»
а т.к. статья Ваша ориентирована на новичков,
… типичные участники сообщества свободного ПО… обычно уже знают.
Вы такой мешаниной смыслов термина "пакет" под конец их всех и запутали
Дополнил:
(UPD от 2017-02-09: кроме тех случаев, где из контекста ясно, что слово «пакет» употреблено в другом смысле)
Моей целевой аудиторией был тот мой знакомый. Я знаю, что его употребление слова "пакет" в разных смыслах не смутит. :) Статья предназначена для людей с таким же уровнем, как у него. :)
А по мне — шикарная статья, очень понятно всё и кратко. В таком удобном и понятном виде к сожалению ничего более не встречал.
Как создавать, собирать, устанавливать и использовать пакеты с программами и библиотеками для UNIX-подобных систем