Slackware Package Management Best Practices

Prev		Next

http://www.linuxquestions.org/questions/slackware-14/slackware-package-management-best-practices-635844/

I was wondering if the more experienced members would not mind sharing the way that they handle/manage packages on their system. Obviously when a Slackware package is available, using installpkg is the logical choice. I also use slapt-get to keep my system up to date with the latest security patches. . .

It'd be nice to have everything in a centralized place so I can just use pkgtool to manage everything. Should I just learn to write SlackBuilds scripts, or are there other alternatives?

Slackware Package Management Best Practices

Here's what I do:

Most packages can be managed using tools like slackpkg/slaptget/swaret (which are scripts around the standard Slackware pkgtool suite). These are usually set up to communicate directly to a Slackware mirror. I use slackpkg.
For software that doesn't come from an official Slackware package repository, but has a package, I'll download it and manually use installpkg. For me, this includes stuff like the proprietary ATI drivers or stuff from linuxpackages.net.
For software that comes as a binary package, but not in Slackware tgz format, like rpms, I'll use src2pkg.
For software that comes as source code, I'll either use src2pkg or a SlackBuild. In the old days, I would configure, compile, and at the make install step run checkinstall to create a Slackware package (then I use installpkg). These days I've found src2pkg to be really good.

Hope this helps. Looks like the only thing you are really missing is src2pkg or trackinstall/checkinstall.

Last edited by jelaiwang : 04-16-08

Slackware Package Management Best Practices

> > if you have already compiled your software you can create the package
> > directly with "trackinstall" (comes with src2pkg). You don't need to
> > re-compile it by running src2pkg.
>
> I remember gnashley saying somewhere that people should use src2pkg and not
> trackinstall as src2pkg does more stuff

there are several good reasons to use src2pkg instead of trackinstall. Mainly because it will keep a better record of any special options you have passed to the configure script, but it is also very helpful when the sources can't be configured and compiled with the usual './configure && make && make install' trio of commands. It is also able to handle sources that use scons, jam, imake and cmake -usually without any help at all. There are only a couple of cases where trackinstall may be able to create a package and src2pkg can't -such as with some pre-compiled binaries which use an interactive installation script.

I'm glad to see that jelaiwang mentioned using src2pkg instead of rpm2tgz — src2pkg does a much more thorough job of converting binary packages from rpm or deb format since the resulting package conetent id subjected to all the usual src2pkg conetent checks — like being sure that directories have the right ownership and permissions, plus stripping the libs and bins, compressing the man-pages if needed and any other special steps which you ask for. rpm2tgz has been around a long time and is part of the official Slackware release, but it is really not adequate for converting *binary* rpm packages, though it works fine for converting srpm's — that is rpm source archives. If you point src2pkg at an rpm source archive, it will unpack it and try to compile it like a regular tar.gz/tar.bz2 source archive.

My advice about keeping your system up-to-date is to just check the Slackware site from time to time for patches to your installed version, or subscribe to receive the security upgrade notices. Then just manually download the packages and use upgradepkg to install them. Trying to keep up with 'current' is not a good idea if you like to keep your installation stable or if you have other things to do besides continually messing with your system.

documented on: 04-17-08, gnashley