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.

« Back: Seek and Ye Shall Find