.comment: Something for Everybody II

By: Dennis E. Powell
Thursday, April 19, 2001 09:04:51 AM EST
URL: http://www.linuxplanet.com/linuxplanet/opinions/3256/1/

Seek and Ye Shall Find

Amazing. Just amazing.

Yesterday I wrote about the need for a unified package handler for Linux that would not just reconcile RPM, DEB, and TGZ packages but would include in the database of installed applications (along with dependencies and the like) those things you build yourself from source.

Konstantin Malakhanov must have had his note pre-written, so quick was he to email a response to my plea. He clued me in on something called "CheckInstall." It is the coolest utility I've ever seen. If you run Slackware or any RPM-based distribution and if you ever compile your own applications, libraries, anything, it is a must-have, a really essential application.

What does it do? Well, I can tell you some things, but I bet that I leave a lot out, because when I think I've figured out everything important about this deceptively small utility (the source download is less than 60k), I happen upon something even neater that it also does. In my explorations so far, I've learned that it:

• Tracks the activities of "make install" and enters the package you've built in your Slackware tarball or RPM-based distribution RPM database.
• Makes your choice of a binary tarball or RPM of whatever it is you've just built.
• Includes in the binary package docs, license, and everything else, not just the binaries themselves.
• Allows for a clean uninstall, because you can use your distribution's regular package uninstall command to get rid of it.
• Allows for a really clean uninstall, because it backs up anything that was changed when you installed the new package you compiled.

Indeed, when you compile it -- and it is the easiest compile since "Hello, World" -- it makes a tarball or RPM of itself!

The imagination swims with thoughts of just how useful this thing could be. Everything you build is automagically backed up in a binary package. While that binary might not work on every machine in the world, chances are that unless you have really weird hardware or some compiler Red Hat decided to loose on an unsuspecting world it will run on other machines, making deployment over a network or mailing to a friend a very easy thing. And, as I said, I haven't fully explored it yet. But just keeping track of the stuff you've built makes it one of the most useful utilities I've ever seen.

The current version is 1.4-beta1. Its developers (and we can give thanks that they are putting their talents to work for Good, because these guys know their stuff) say they're working on adding DEB support.

Please don't think I'm complaining when I consider where things could go from here.

A Grand Solution to the Package Problem

The most difficult part of my idea for a Master Package Manager -- trapping "make install" and entering it into the database -- is solved by CheckInstall. The next part is deciding upon and establishing a grand master database. CheckInstall handles the RPM database and the one of binary tarballs that Slackware maintains, and soon will ride herd on Debian, too. Debian's alien program allows incorporation and back-and-forth conversion of RPMs, SLP's, .tgz's and .tar.gz's. So the makings of the master database are largely there.

Now all that's needed is bringing it all together. Debian seems to have the best way of importing other packages, and there's little reason to re-invent the wheel. With a little work (or maybe none), it would be possible to forego the RPM database entirely, and the one for tarballs, and fold it all into a Debian or modified-Debian database. There would need to be a little utility that would read the existing distribution-specific database into the master database.

Then, one could compile, could install RPMs, could build from SRPMs, could apt-get DEBs and source via apt-get, could use binary tarballs, and could keep it all straight. Users would not be tied to any specific distribution, and in an era when distributions are popping up, disappearing, repositioning themselves, and in other ways proving unreliable for the mere user, this is important.

But why stop there?

A Grand Master Demystifier

Now, for fun, let's imagine an X-based frontend for all of this. I'm drawn to remember an application popular during the KDE-1.x days called KPackViewer. It provided a listing of installed packages and what they contained as well as a way of looking inside uninstalled packages. That's a dandy start. Let's expand on it.

To start, we need to give it a terminal window in which source code can be compiled. Because this terminal will be for this purpose alone, let's give it some settings, some things that people who build their own apps are likely to forget. Compiler flags are one. XConfig in the Linux kernel source does some of this when it asks the user to specify the processor for which the kernel is being built. Another area where users could be prompted is the prefix -- where the results are to be installed -- and other configure options. This could be made especially useful if it could read the options of specific use to the package in question (example: for QT, one typically wants to do -sm, -gif, -system-jpeg, -system-libpng, -xft, and -no-g++-exceptions, with -thread and -no-openGL as other popular choices). There could even be little buttons for "make" and "make install," with the latter prompting for the root password. Yes, compiling under X isn't as fast as compiling from a pure console. Tough.

Why stop there? Why not allow users to log what's happening, maybe with the possibility of highlighting a section and, upon clicking on "Help," getting an explanation of what's taking place here? Likewise with error messages, warnings, and other things that cause the throats of newbies to tighten. If there's an unmet dependency, why not specify whether a file doesn't exist, whether it's there but not where it was expected to be, or whether it's there but the wrong version? The wonderful Dict program (and KDict, its dandy KDE port) will go out on the Web to provide definitions for words or phrases. Why not let those problems with dependencies get solved by a Debian-style ability to go get it and install it right now, so the compile can proceed?

My thoughts here are not so much to make compiling easier -- it isn't very difficult as things are now, with all the great tools we have available -- but to make it more understandable. That prompt on an otherwise blank console is a pretty daunting thing for the first-time compiler, and I daresay there are few of us who know everything about the process. The X version of my notion of a grand package handler would include the things that would enable anyone who cared to do so to learn all about compiling while doing it.

The distinguishing feature of Linux is that it's Open Source. We can get the source code. Yet the push has been in the direction of forgetting the source entirely and getting users to grab RPMs or DEBs or whatever YaST produces. It's to everyone's benefit to have source code readily accessible to every user.

In addition to the wonderful things that CheckInstall does, it has done one thing more: Caused me to think that my flight of fancy outlined above is entirely possible, most of it by bringing together things that already exist.

I can't think of anything that would better promote Linux, and suck the wind out of that "steep learning curve" nonsense.