Pkgtool, and the Meaning of Package Management

[blackbelt_jones]

Here's a quote from Slackware Linux Essential, the official Slackware manual:

There's a myth that's been going around ever since RedHat debuted RedHat Package Manager, that Slackware has no package management tool. This simply couldn't be further from the truth. Slackware has always included a package manager, even before RedHat existed. While not as full-featured or as ubiquitous as rpm (or for that matter deb), pkgtool and its associated programs are every bit as good at installing packages as rpm. The truth about pkgtool is not that it doesn't exist, but that it doesn't do any dependency checking.

Apparently many people in the Linux community think that a packager manager must by definition include dependency checking. Well, that simply isn't the case, as Slackware most certainly does not. This is not to say that Slackware packages don't have dependencies, but rather that its package manager doesn't check for them. Dependency management is left up to the sysadmin, and that's the way we like it.

If you've cut your teeth on package managers like YAST, YUM, or apt-get, as I have, the idea of package management without dependency management may be hard to get your mind around. Handling dependencies is central to my idea of what package management means. I hope this doesn't sound sarcastic or derisive, but if pkgtool doesn't track dependencies, what does it do? Could someone give me an overview?

[bwkaz]

I'd guess it's a lot like the package management scheme that I use: All it does is installs a package for you, and lets you (cleanly and fully) uninstall it later.

The scheme I use is to create a new (non-root) user for each package, and install each package as that user. Then again, I use LFS, so that's part of the difference there. Anyway, I can uninstall a package by finding all files owned by that package's user, and deleting them. And I can install a package by compiling it and then doing "make install". (The system also has some special permissions set on certain directories to ensure one package doesn't overwrite or delete files from another.)

However, this doesn't give me any info at all on dependencies.

I suspect pkgtool works similarly -- when you install a package, it just copies the files into their final places, and adds each file to its database so it can remove them if you want to remove the package. But you don't find out about dependencies until you try to run the program (or use the library).

[blackbelt_jones]

I'd guess it's a lot like the package management scheme that I use: All it does is installs a package for you, and lets you (cleanly and fully) uninstall it later.

The scheme I use is to create a new (non-root) user for each package, and install each package as that user. Then again, I use LFS, so that's part of the difference there. Anyway, I can uninstall a package by finding all files owned by that package's user, and deleting them. And I can install a package by compiling it and then doing "make install". (The system also has some special permissions set on certain directories to ensure one package doesn't overwrite or delete files from another.)

However, this doesn't give me any info at all on dependencies.

I suspect pkgtool works similarly -- when you install a package, it just copies the files into their final places, and adds each file to its database so it can remove them if you want to remove the package. But you don't find out about dependencies until you try to run the program (or use the library).

That almost sounds like I'd be better off compiling from source, which will at least inform me of dependancies during the compiling process, usually while configuring. Of course, compling probably takes longer, especially when those dependancies really start to pop up, and then more dependancies for those dependancies. But you can always get through it with patience and a diciplines approach. There is no such thing as "dependancy hell"... only dependency purgatory.

[JohnT]

A new tool for maintaining packages that requires a thoughtful look.
http://tukaani.org/pkgtools/

Use Swaret if you want/need to check dependencies.
http://swaret.sourceforge.net/

[happybunny]

for what its worth: http://labix.org/smart

[JohnT]

for what its worth: http://labix.org/smart

Looks possible!!

[clw54]

I just install the entire Slackware distro except for the KDE language stuff. The only package installs left to do are in the extras directory, if needed. There are also periodic updates posted on websites and it's easy to download them and install them using upgradepkg. Dependencies this way aren't an issue. Slackware includes a lot of libraries, so many sources will compile without problems.

[JamminJoeyB]

I actually prefer the Slackware way of packages. pkgtool may not do dependencies, but I hated hunting for rpm after rpm, just to install one piece of software. That is why I left the RPM based distros long ago.

And compiling for source doesn't take that long on most PCs these days. Ok, unless you are doing a stage 1 Gentoo install, it doesn't take that long.

Besides sometimes you need the added control you get from compiling from source. Those configure options can really be helpful.

[ph34r]

When I used slack, I simply installed *everything* except the bsd-games catagory, and then anything else I added was either a static package (Quake2, etc) or installed from source with prefix=/opt/packagename-version

[techwise]

the idea of package management without dependency management may be hard to get your mind around

Thats exactly why any sane Linux user with real work to get done always returns to Debian. The fact is, there is no package management system as rigorously coordinated and adhered to as dpkg. Many confuse apt-get with dpkg as being the package manager. Its not. Apt-get is just the tool for easily handling the packages. Dpkg is the workhorse.

Anyone that uses Debian or is thinking about using it must read the Martin Kraftt book "The Debian System" from No Starch Press. You will acquire a whole new admiration and respect for the Debian way of doing things. Its a fantastic book. It can be read entirely without sitting in front of a Debian installation, its that interesting.

Cheers

M

[blackbelt_jones]

Thats exactly why any sane Linux user with real work to get done always returns to Debian. The fact is, there is no package management system as rigorously coordinated and adhered to as dpkg. Many confuse apt-get with dpkg as being the package manager. Its not. Apt-get is just the tool for easily handling the packages. Dpkg is the workhorse.
M

I didn't know that. This really gets to the heart of what I was trying to talk about here, which is what "package management" really means, not to get into a debate about the relative merits of Slackware package management.

I've got Debian runnning on my other computer, and whatever you call the Debian package manager, it really is pretty awesome. I got interested in trying Slackware again after I couldn't get Debian working on this computer, and was forced to try Vector Linux SoHo, which I found really powerful and easy. Vector is Slackware based.

I'm kind of impressed with Slackware, but I can't get it to do everything I want it to do. Like I've said before, it's my fault, not the distro's fault... but it may be the distro that has to go.

[JohnT]

For futher edification on the subject we have an additional view......with some replies.
http://lxer.com/module/newswire/view/93393/

[blackbelt_jones]

For futher edification on the subject we have an additional view......with some replies.
http://lxer.com/module/newswire/view/93393/

This article is indeed edifying. For one thing, this is the first time I understood that you're supposed to build your own packages for the Slackware package manager.

But I'm a little skeptical about this whole "Ubuntu Sucks" angle. God knows, i've done my *****ing about Ubuntu, but this is the first time I've ever heard of "the bloat and system degradation that is frequently associated with Debian-based distros". I'm not skeptical that it exists, so much as I''m skeptical that it's all that significant. From the desktop, Slackware, SUSE, and Debian all run nicely, in spite of my tendancy to install huge globs of software, so that I can run my favorite gnome apps, and my favorite kde apps from a gui that is neither gnome nor kde, and be reasonably confident that when I want to compile something, the development packages are in place. This saves me a lot of time, and I really don't think that an eighth of a second here, a sixteenth of a second here, are going to add up to much.

(Of course, these performance issues may matter a lot more for, say, a heavy-traffic webserver.)

Still, the article makes a strong case for Slackware being a "classic". People who want the simplicity and control that Slackware affords should be able to get it. I didn't need to be further convinced of Slack's relevance, but I was anyway when a recently acquired computer wouldn't run Debian, and I was forced to take up Vector Linux. Slackware may be the most personally difficult distro I've ever used, but Vector is the easiest! Slackware, even more than Debian, could well prove to be the sire of some important general-user distros in the future.

I still want to run Debian off my main Desktop-- not Slackware, and not Vector, either. I've been working on fixing the problem with my graphics card. If I don't manage to get Etch to favor my NVidia card over the onboard Intel card that doesn't work, I may be able to get Sid installed via Kanotix. But I'm going to keep a Slackware partion on my second computer. There's a kind of siren call to Slackware with its simplicity and geek reputation. Someday I'll lick it.

[Calipso]

I actually prefer the Slackware way of packages. pkgtool may not do dependencies, but I hated hunting for rpm after rpm, just to install one piece of software. That is why I left the RPM based distros long ago.

Correct me if I'm wrong, but don't you still have to hunt down software/library after software/library to install software when you use pkgtool or source?

I mean if package A needs library B, and you don't have it, you have to go find and install it. You're simply looking for the tarball in this case instead of an RPM. I don't quite see the difference between the so called rpm hell and tarball hell.

[bwkaz]

Correct me if I'm wrong, but don't you still have to hunt down software/library after software/library to install software when you use pkgtool or source?

Not if the package has an optional dependency on the library, and you don't mind missing out on those features.

For instance, on the Debian server at work, we have Apache 2.2.x installed via apt-get. On my own web server at home, I have Apache 2.2.0 installed from source. On Debian, apache depends on Berkeley DB, a separate APR, and I think even the PostgreSQL client libraries. At home, I don't care if I can't use a database-backed credential store, so I've just disabled the code that requires Berkeley DB and/or the PostgreSQL client library (by using the appropriate options to ./configure).

So you're right for some things: sometimes you do have to go hunt down a bunch of other tarballs. But some things (especially the dependencies that the package author considered "optional" but your distro's binary package made "required") aren't really needed anyway.

(Note that Debian isn't the only distro that does this: RPMs do it a lot too. And any package format that distributes binaries will also do it. Gentoo's portage system is a notable exception, but it can only get away with doing this because it compiles almost everything.)