Sm@cker's Homepage

За редким исключением, большинство пользователей Linux пользуются пакетными дистрибутивами. Т.е. свою систему получают, установив набор программ, разбитых на отдельные пакеты, содержащие дополнительную служебную информацию, что облегчает управление установленным ПО — удаление, добавление, обновление и т.п. действия. Казалось бы, подобного рода организация должна привести к тому, что пользователь будет все свои потребности в ПО удовлетворять общаясь исключительно с менеджером пакетов, беря «всё готовое». Однако, на практике это не совсем так.

 

Конечно, для многих людей пакетный менеджер предоставляет всё необходимое — если дистрибутив достаточно развитой, за ним стоят репозитории с тысячами и десятками тысяч готовых к эксплуатации пакетов. И тем не менее, зачастую возникает потребность установить некое ПО из исходного кода. Причин тому может быть несколько, вот самые очевидные из них:
- Слишком старая с точки зрения пользователя версия ПО в репозитории;
- Отсутствие нужной программы в репозитории;
- Необходимость использовать модифицированную версию программы, скажем, собранную с большей оптимизацией;
В таком случае подчас предлагают «прикрутить» к дистрибутиву пакет из какого-то другого, близкородственного. Я против такого подхода, считая, что наиболее верными вариантами являются либо использование родного пакета, либо собранного из исходного кода.

 

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

 ./configure
 make
 make install 

Однако при следовании этой мантре мы постепенно окажемся в ситуации, когда часть (и довольно значительная) ПО в системе окажется «беспризорным»: если для ПО, установленного из пакетов, мы можем установить происхождение или местонахождение каждого отдельного файла, удалять «без следа» целый пакет, отслеживать версии, конфликты, проверять целостность и т.п. — то к софту, установленному посредством make install, подобная система управления оказывается неприменима. Тем самым мы не только сделаем бессмысленной идею пакетного дистрибутива, но и осложним себе управление «беспризорным» софтом, когда придет время его удалять или обновлять. Предположим, что через год мы захотим удалить «беспризорную программу». Тогда нам понадобится исходный архив с ней (не целиком, разумеется), в надежде, что кроме цели install есть цель и uninstall, что далеко не всегда так. Если же мы возьмем другую версию исходного кода (если старая ушла в небытие и недоступна более, что также случается), то может оказаться, что за прошедшее время изменились названия или пути файлов, и новый uninstall удаляет уже не то, что мы ставили. Наконец, в худшем случае нам останется вручную искать все файлы, относящиеся к нашей программе... бррр...
Выход из этой ситуации лежит на поверхности — нужно собранный из исходного кода софт собирать в пакеты. Технология сборки пакетов не является секретом и относительно несложна. Но сегодня я расскажу о программе, которая облегчит эту задачу, собирая нужные пакеты автоматически.

 

Утилита checkinstall работает примерно следующим образом: вставая на место make install в указанной мантре (т.е. checkinstall должен применяться уже после собственно сборки софта, он не подменяет собой make или другие способы сборки), она отслеживает действия установочного скрипта (что копируется, куда, под каким именем, с какими правами и т.п.) и из них создает установочные инструкции для будущего пакета. Справедливости ради скажу, что checkinstall умеет работать не только с make install, но и с практически любым скриптом, который что-то куда-то будет копировать, включая scons и прочие варианты. Скажем, если некую программу предлагается устанавливать командой ./myowninstaller.pl —instl, то checkinstall поймет и это, нужно будет только указать нужную команду в конце строки, например:

 checkinstall -R --install=yes ./myowninstaller.pl --instl 

По умолчанию предполагается, что способом установки будет именно make install.

 

Checkinstall умеет собирать пакеты RPM (как в примере выше), DEB и TGZ, сразу устанавливать собираемые пакеты (конечно, тут вам скорее всего понадобятся права root), добавлять свежеиспеченные библиотеки в /etc/ld.so.conf и многое другое. Вот чего вы можете ожидать от checkinstall 1.6.1:

 

 Usage: checkinstall [options] [command [command arguments]]
 
 Options:
 
 *Package type selection*
 
 -t,--type=<slackware|rpm|debian> Choose packaging system
 -S                               Build a Slackware package
 -R                               Build a RPM package
 -D                               Build a Debian package
 
 *Install options*
 
 --install=<yes|no>             Toggle created package installation
 --fstrans=<yes|no>             Enable/disable the filesystem translation code
 
 *Scripting options*
 
 -y, --default                  Accept default answers to all questions
 --pkgname=<name>               Set name
 --pkgversion=<version>         Set version
 -A, --arch, --pkgarch=<arch>   Set architecture
 --pkgrelease=<release>         Set release
 --pkglicense=<license>         Set license
 --pkggroup=<group>             Set software group
 --pkgsource=<source>           Set source location
 
 --pkgaltsource=<altsource>     Set alternate source location
 --pakdir=<directory>           The new package will be saved here
 --maintainer=<email addr>      The package maintainer (.deb)
 --provides=<list>              Features provided by this package (.rpm)
 --requires=<list>              Features required by this package
 --rpmflags=<flags>             Pass this flags to the rpm installer
 --rpmi                         Use the -i flag for rpm when installing a .rpm
 --rpmu                         Use the -U flag for rpm when installing a .rpm
 --dpkgflags=<flags>            Pass this flags to the dpkg installer
 --spec=<path>                  .spec file location
 --nodoc                        Do not include documentation files
 
 *Info display options*
 
 -d<0|1|2>                      Set debug level
 -si                            Run an interactive install command
 --showinstall=<yes|no>         Toggle interactive install command
 -ss                            Run an interactive Slackware installation script
 --showslack=<yes|no>           Toggle interactive Slackware installation script
 
 *Package tuning options*
 
 --autodoinst=<yes|no>          Toggle the creation of a doinst.sh script
 --strip=<yes|no>               Strip any ELF binaries found inside the package
 --stripso=<yes|no>             Strip any ELF binary libraries (.so files)
 --addso=<yes|no>               Search for any shared libs and add
                                them to /etc/ld.so.conf
 --reset-uids=<yes|no>          Reset perms for all files/dirs to 755 and
                                the owner/group for all dirs to root.root
 --gzman=<yes|no>               Compress any man pages found inside the package
 --docdir=<path>                Where to put documentation files
 --umask=<mask>                 Set the umask value
 --exclude=<file|dir[,...]>     Exclude these files/directories from the package
 --include=<listfile>           Force the inclusion in the package of the
                                files/dirs listed in "listfile"
 --inspect                      Inspect the package's file list
 --review-spec                  Review the spec file before creating a .rpm
 --review-control               Review the control file before creating a .deb
 --newslack                     Use the new (8.1+) Slackware description format
                                ("--newslack" implies "-S")
 --with-tar=/path/to/tar        Manually set the path to the tar binary
                                in this system
 
 *Cleanup options*
 
 --deldoc=<yes|no>              Delete doc-pak upon termination
 --deldesc=<yes|no>             Delete description-pak upon termination
 --delspec=<yes|no>             Delete spec file upon termination
 --bk                           Backup any overwritten files
 --backup=<yes|no>              Toggle backup
 
 *About CheckInstall*
 
 --help, -h                     Show this message
 --copyright                    Show Copyright information
 --version                      Show version information
 

 

После запуска (если не заданы соответствующие параметры) checkinstall предоставит возможность задать тип и имя пакета, версию и т.п. информацию в диалоговом режиме:

 

 This package will be built according to these values:
 
 1 -  Summary: [ Terminus Font ]
 2 -  Name:    [ terminus-font ]
 3 -  Version: [ 4.20 ]
 4 -  Release: [ 1 ]
 5 -  License: [ GPL ]
 6 -  Group:   [ Applications/System ]
 7 -  Architecture: [ noarch ]
 8 -  Source location: [ terminus-font-4.20 ]
 9 -  Alternate source location: [  ]
 10 - Requires: [  ]
 11 - Provides: [ terminus-font ]
 
 Введите номер для изменения параметра или нажмите ВВОД для продолжения: 
 

 

После задания нужных значений соберется, а если укажете —install=yes, то и установится, новый пакет. Теперь с его содержимым можно будет работать централизовано, не разводя беспорядка. Лично я перешел к использованию checkinstall уже очень давно и несказанно этому рад.

 

Кстати, готовые пакеты в ASP Linux складываются в /usr/src/asplinux/RPMS/архитектура_пакета, оттуда их можно брать для последующей установки на другие машины (скажем, если у вас десктоп и ноутбук используют одну и ту же версию дистрибутива).

 

Официальная страница checkinstall
http://www.asic-linux.com.mx/~izto/checkinstall/