Что бы вы ни делали, убедитесь, что в конечном итоге вы прошли через систему управления пакетами вашего дистрибутива (например, rpm для Fedora / Mandriva / RH / SuSE, dpkg для Debian / Ubuntu и т. Д.). В противном случае ваш менеджер пакетов не будет ничего знать о пакетах, которые вы установили вручную, и вы в лучшем случае будете иметь неудовлетворенные зависимости, а в худшем - мать всех беспорядков.
Если у вас нет менеджера пакетов, тогда возьмите его и придерживайтесь его!
Я бы посоветовал вам научиться делать собственные пакеты. Вы можете начать с просмотра исходных пакетов вашего дистрибутива. На самом деле, если все, что вы хотите сделать, это обновить MyPackage до версии 1.2.3, исходный пакет вашего дистрибутива для 1.2.2 обычно можно адаптировать с простым изменением версии (если нет исправлений, но это уже другая история ...) .
Если вам не нужны пакеты с качеством распространения (например, пакеты с разделенной библиотекой / приложением / отладкой, поддержка нескольких архитектур и т. Д.), Обычно легко преобразовать типичный сценарий configure & make & make install в подходящий пакет с исходным кодом. Если вы можете убедить ваш пакет установить в каталог, а не в /, то обычно все готово.
Что касается checkinstall, я использовал его в прошлом, и он работал для пары простых пакетов, но мне не понравился тот факт, что он фактически позволил пакету установить себя в мою систему до создание пакета rpm / deb. Он просто отслеживал, какие файлы были установлены, чтобы упаковать их, что не защищало от нежелательных изменений. Да, и для работы ему нужны были корневые привилегии, что для меня является еще одним важным камнем преткновения. И давайте не будем вдаваться в то, что происходит со статически связанными основными утилитами ...
Кажется, что большинство подобных инструментов работают таким образом, поэтому я просто научился создавать свои собственные пакеты The Right Way (TM) и позволить checkinstall и друзьям бездельничать в других местах. Если вы все еще заинтересованы, однако, здесь есть список похожих программ:
http://www.dwheeler.com/essays/automating-destdir.html
PS: BTW checkinstall был обновлен в конце 2009 года, что, вероятно, означает, что он все еще достаточно актуален.
EDIT:
По моему мнению, самый простой способ выполнить обновление до последней версии пакета, если он недоступен в репозитории, - это изменить исходный пакет последней версии в вашем дистрибутиве. Например. для Centos исходные пакеты для последней версии находятся здесь:
http://mirror.centos.org/centos/5.5/os/SRPMS/
http://mirror.centos.org/centos/5.5/updates/SRPMS/
...
Если вы хотите обновить, например, php, вы получаете последнюю версию SRPM для вашего дистрибутива, например, PHP-5.1.6-27.el5.src.rpm. Тогда вы делаете:
rpm -hiv php-5.1.6-27.el5.src.rpm
, который устанавливает пакет с исходным кодом (только исходники - он ничего не компилирует). Затем вы переходите в каталог сборки rpm (в моей системе mandriva это / usr / src / rpm), вы копируете последний архив с исходным кодом php в подкаталог SOURCES и проверяете, что он сжат так же, как и только что установленный tarball там. После этого вы редактируете файл php.spec в каталоге SPECS, чтобы изменить версию пакета, и соберите двоичный пакет примерно так:
rpmbuild -ba php.spec
Во многих случаях это все, что потребуется для нового пакета. В других случаях все может быть немного сложнее - если есть исправления или если в пакете есть серьезные изменения, вам, возможно, придется сделать больше.
Я предлагаю вам ознакомиться с командами rpm и rpmbuild (их справочные страницы довольно хороши, но немного обширны) и проверить документацию по написанию spec-файлов. Даже если вы решите использовать официальные репозитории backport, полезно знать, как создавать собственные пакеты. Смотри также:
http://www.rpm.org/wiki/Docs
РЕДАКТИРОВАТЬ 2:
Если вы уже устанавливаете пакеты из исходного кода, использование rpm действительно упростит процесс сборки в долгосрочной перспективе, за исключением поддержания целостности вашей системы.Причина этого заключается в том, что вам не придется запоминать причуды каждого пакета самостоятельно («оооо, теперь я помню, foo нужно, чтобы я добавил -lbar к своим CFLAGS»), так как процесс сборки будетв файле .spec, который можно представить как несколько структурированный скрипт сборки.
Что касается обновления, если у вас уже есть файл .spec для предыдущей версии пакета, есть две основные проблемыс которыми вы можете столкнуться, но оба они существуют независимо от того, используете ли вы rpm для сборки вашего пакета или нет:
Патч, который был применен к предыдущей версии дистрибутивом, больше не применяется.Во многих случаях патч уже был применен к исходному пакету, поэтому вы можете просто удалить его.В других случаях вам, возможно, придется отредактировать его - или, я полагаю, если вы сочтете это неважным, вы тоже можете его удалить.
Пакет изменился каким-то существенным образом, что повлияло, например, на расположение файловэто устанавливает.Вы читаете примечания к выпуску для каждой новой версии, не так ли?
Помимо этих двух проблем, обновление часто сводится к простому изменению номера версии в файле спецификации изапуск rpmbuild - даже проще, чем установка из tarball.
Я бы посоветовал вам взглянуть на учебные пособия или исходный пакет для некоторых простых программ, таких как:
http://mirror.centos.org/centos/5.5/os/SRPMS/ipv6calc-0.61-1.src.rpm
http://mirror.centos.org/centos/5.5/os/SRPMS/libevent-1.4.13-1.src.rpm
Если у вас есть опыт сборки пакетов из тарбола, использование rpm для создания программного обеспечения на самом деле не является большим скачком.Однако это никогда не будет так просто, как установка готового бинарного пакета.