The lack of automatic dependency resolution in Slackware's package
management system is seen by some as a fatal problem for the distribution.
But Vincent Batts came to Camp KDE to point out some advantages of
Slackware's laissez faire attitude toward dependencies when testing
a rapidly changing set of packages under development, like, for instance,
the early state of KDE 4. The flexibility of being able to easily build
packages based on the KDE source code and install them as needed, while being
able to back out as problems arose made it easy for him to investigate the
changes that came with KDE 4.
Batts said that when KDE 4.0 was released, he was firmly happy with 3.5,
and not yet willing to switch. He was, however, curious about the new KDE
world, and wanted to "see what I might be missing". In trying
to check it out, he was regularly breaking his systems, which is a Linux
user's right, he said, but that breakage led him to using Slackware to
make it easier to manage his KDE 4 investigation.
KDE 4 brought a lot of new dependencies, which he found much easier to
manage with Slackware as opposed to a packaging system like RPM that does
dependency handling. Slackware has a "simplicity in component
handling and upgrades" that is lacking in other systems. You can
use RPM and the --force option to install package without their
dependencies, or to override other requirements, but it can lead to various
problems that can be difficult to recover from.
For Slackware, though, there is a "managed set of packages",
with most dependencies already available in the base system, and
"everything plays nicely together". That sounds like the
situation with most distributions, but Batts pointed out some significant
differences, as well.
Slackware packages are not much more than a tarball and a shell script.
There are no domain-specific languages and no "automagic" in the package
management system. As he was building the KDE 4 code, if he ran into a
dependency that he didn't have, he got the source, built it in the
canonical way, and easily turned it into a Slackware package using the
$ make install DESTDIR=`pwd`/tmp
$ cd tmp
$ makepkg -l y ../pkg_name.tgz
$ sudo upgradpkg --reinstall ../pkg_name.tgz
One can also use explodepkg to unbundle the package, fix any
problems in it, and then makepkg/upgradepkg to recreate
and reinstall the package. In working with the early KDE 4 packages, Batts
got "good at rendering systems useless", but was able to
fairly easily return the system to a known state. It is one of the
benefits of not having a dependency chain, he said, because you can try
things out, then back them out as needed.
To do that, Batts recommended having a local mirror or DVD of the Slackware
release, then you can roll back any changes on a running system. From the
top of the Slackware tree, a simple:
# upgradepkg --reinstall */*.t?z
will reinstall all of the packages from the release, overwriting any that
appear in the core set and have been changed. A
" will then remove any packages that
are not part of the core set, essentially resetting the system back to the
"just installed" state.
One of the attendees asked about how KDE was to work with as an upstream
and Batts seemed to be pretty happy with the project. He likes that you
can get tarballs of each of the major subparts of KDE without having to get
a tarball for each individual program. For example the KDE education
tarball has all of the applications that make up that piece (e.g. KStars,
Marble) which one can then subdivide into Slackware packages as they are
built if that's desirable.
The dependencies have greatly increased with KDE 4, but
"it is still pretty manageable", he said. One of the reasons
that GNOME was removed from the Slackware core several releases ago was
that the dependencies got out of hand: "Try to build GNOME from
source, it will be instructive", he said.
It was interesting to hear one of the oft-heard weaknesses of Slackware
turned on its head in Batts's presentation. While dependency tracking and
handling can be useful—very useful at times—there are times
when it can just get in the way. When choosing a distribution to use, it
may make sense to look at Slackware, especially for systems that will be
undergoing rapid, pervasive changes.
to post comments)