Broken Links: Software Installation

One of the main burdens of entering the Linux world for users of so called 'easy to use' OSes like Windows and MacOS is the issue of software installation, there's really no standard software installation method, apart from compilation from source. Distributions like Red Hat, SuSE and Mandrake utilise the .rpm package system. For  users with other tastes, distributions like Debian and Xandros utilise the .deb packaging system and others prefer a powerful, source based distribution like Gentoo or Lunar-Linux.

This would probably be the biggest downfall behind customised distributions at the moment, although these methods all have good and bad points, users will generally stick religiously to one packaging method and therefore, one style of distribution. Freedom of choice, scalability and customisability are the biggest strengths behind free software today and it certainly applies to Linux distributions, but this freedom of choice and generally 'religious' zeal towards each method is creating a serious divide between users of all forms of free Unices and holding back progress and intake of new users from different style OSes.

The primary issue of concern for most people from a Windows background that I know of is the software installation method and then the usage afterwards. Although the command line under Unices is very powerful and should never be hidden away from X based desktops, it always seems to alienate users from environments like Windows and MacOS. These users generally don't want to undertake the 're-education' required to change over to such a drastically different method to what they've “grown up with”. 

What Do They Want?

The majority of the world now uses Microsoft Windows, the installation method is a very familiar, “Next, Next, Next, Yes, No..... click on something in the Start Menu”, guided by a series of obviously marked buttons and generally one installation method. I know users that would rather put up with virus after virus and crash after crash than open up and xterm to compile or run a program. What most users (not including veteran Linux users) want is the following;

1. An installation process that uses a GUI.
2. The process should have default installation routes so that the familiar,
3. “Next, Next, Next.....” is what they're used to and what they probably still want.

After the package has been installed, the user then wants to access the program they've just installed by choosing the program from a list in an easily available menu, from a logical area.

Currently we have installation by something like “rpm -ivh package_name.rpm” for an .rpm package, or for source we have to extract the files from a compressed tarball (or various other compression methods) and then do a “./configure; make; make install”. There are various other methods available too, like .deb packages and various front-ends, like SuSE's package manager that will actually integrate any newly installed packages to a SuSE specific menu which is available under most installed X desktops, similar to Debian's method. All of these methods certainly have advantages and disadvantages, but all are distribution dependent and this makes it an awful state for Linux newbies.

What Do We Need?

In order for X to gain a major foothold in the desktop market and grab the average user (we certainly aren't average), it's probably fair to say that we need a distribution independent, X standard, GUI driven package manager.

Currently there are a number of programs that have installation programs that are GUI driven and do allow for menu integration (although usually only for KDE and GNOME, but that's an issue best left for another Broken Link), programs like Quake 3 and OpenOffice.org have a familiar looking interface for newbies, with the usual “Next, Next....” interface provided by an easy to understand GUI, but these methods are hardly what called be called 'X standard' and are generally reliant on an independently produced GTK interface.

 The above installation method is also usually limited to installation of pre-compiled binary files also, therefore not allowing for the optimisation and speed provided by compilation from source. As you can see, there are plenty of reasons why many have been wary of Linux for some time now and many attempts to make a nice GUI installation have failed from lack of support by other developers. What we hope to achieve from this article is a start to unification from developers in the direction of achieving this goal.

Below is my own idea for a project framework, I'm not suggesting that my method is perfect and that my words should be followed as gospel, but please take it on-board as a suggestion and add to it or constructively criticise it as much as possible so that we may actually get a start on this project as a community.

The Suggested Framework

No matter what distribution is in use, all distributions have the ability to copy binary files to a pre-defined destination or to compile files from source and then copy them into place, but that's a given. We also have a strength that is Unix wide though, a permission based filesystem, and we can seriously use this to our advantage in the hope of winning more users. This is also the basis of the idea I'm putting forward.

Private/Public

Under Unix based systems, the filesystem has user based permissions, generally which are previously decided on by the task that the file is meant for, effectively making certain files for general public use (usually harmless to the system's integrity) and other files private, whether for security or privacy reasons. 

Examples of public files are executables like “ls”, or a system wide audio player etc. Harmless to the system and potentially useful to everyone, publicly readable files form the basis of a standard Unix based system. Examples of private files are those contained within a user's home directory, perhaps diary entries, photographs, anything like that which is probably only useful to the user at the time and would probably want to be kept private. On the other side of the scale are files like administration utilities, only the super-user can access them for security and stability reasons.

Drawing on the strengths of this method of file handling, this helps tie us in for the meat of the idea, how it actually would work.

The Interface

All of the next few sections are obviously a GUI front-end based on a command line base, the easiest way to think of it is this way:
	For pre-compiled binaries, a ./configure and make install script with a   GUI front-end.
	For something still source based, a ./configure, make and make install script with a GUI front-end.
My own hopes for the project if it were to prove successful would be for most developers to opt for keepings things source based, as the benefits of a completely optimised package being the defacto standard would see a big performance in Unix based systems in general.

Private/Public

Getting onto the interface and what would be presented to the user, two simple buttons would be provided, a choice for a Private Installation or a Public Installation. This is the first major decider of what happens with the package and sets off the deciding trigger for the biggest fork in the entire process.

A Public Installation is what we're all familiar with so far, after a package has been compiled (if need be), the compiled files are then copied to a pre-defined destination and then the permissions for the said files are set, which everyone can read from but not write to. Obviously this step would require root privileges, so a prompt asking for the root password would appear before a user could continue with such a step, or else it would be an obvious and major security flaw. If the user doesn't have the root password or doesn't wish the new program to be publicly available, then they would have to choose a Private Installation.

A Private Installation is the new idea in this. Instead of the files being places in a publicly readable/executable location, the files are installed privately into something like ~/bin/ (ie. /home/nhoj/bin/). As you can tell, only the user who installed the package can run the new program, therefore not affecting the rest of the system.

As far as programs that would require root privileges to run properly are concerned, probably the best way to approach this would be that a starting trigger in the package would make sure that only the option for a Public Installation is available.

Menu Entries

After these installation steps are then completed, the user would then have the option to integrate the new program into the menu. Here again, we would have an issue with Private or Public installations. In the case of a Public Installation, if the person installing the new program wishes for the program to be available in every user's menu, then they would have the option to have the new entry in a system wide menu, affecting everyone.

As for a Private Installation's menu integration, if the user chooses to integrate the new entry into their new menu, then only that user's menu is affected and no system wide change is made. The issue of menu entries over multiple desktops, like KDE, GNOME, BlackBox, etc... is obviously going to spring up, but the method of menu handling over multiple desktops is of secondary importance in a current setup and is best left for the next instalment of Broken Links.

Pathing

The next issue to address is of how people would handle the actual paths that these programs are installed to, would developers have to do all their Makefile scripting for the two different types of installation, and worse yet, what about different file hierarchies available, like Red Hat, Debian or FreeBSD? There's a simple workaround for that which also helps in portability.

By a simple scripting method, all of the files would have something like a "[prefix]" flag before them. The [prefix] flag would be a pre-defined path destination, so that when someone chooses a particular type of installation on  any sort of system, the path destination has already been chosen. As an example, if an executable were to be copied to /usr/bin/ on a standard Linux system with the current installation methods available, the installation script would point to [prefix]/bin.

In this case, with a Public installation, [prefix] would be set to /usr, and with a Private Installation, [prefix] would be set to ~ (/home/(user) for the newbies). When the user initially chooses what kind of installation they want, the [prefix]'s path is then filled in accordingly. At the end of the operation, the new file still ends up in /usr/bin or /home/nhoj/bin accordingly. 

The way that this could help in porting to other file hierarchies is that the pre-defined destinations for the [prefix] could be changed according to whatever distribution is in use, therefore a developer only would need to support one universal Unix hierarchy instead of having to change the installation scripts for all the various versions of Unix available (you never know, you might even be able to make a Windows port if you're clever).

Feedback

So there's the idea in a nutshell, please give us your feedback on the idea and various parts which may be technically flawed etc, in the forums provided (insert link). Before making any kind of feedback though, if you have followed a link directly to this page, please read the introduction to how this section works (insert link), so that we can keep this new project organised and running efficiently each month. We look forward to your comments and ideas, and hope that this new section can start a real move forwards for Open Source Software.

John Knight