Linux Software Installation, Part IV: Solutions

package
After I wrote about real user needs this article of my series about the software installation on Linux deals with the possible ways to solve the problem.

As I showed there is a strong need for solving the current problem of installing software on Linux. The first, maybe for a Linux newbie most obvious solution is the one which is most unlikely to happen: that all major distributions suddenly turn to one package manager. Also, I doubt that most of all users suddenly turn to a specific distribution, which would also effectively solve the problem.

Other attempts like alternative binary packages (like Autopackage) run into problems as soon as the native package manager comes into play: the native package manager does not know anything about the software of the Alternative package, and these conflicts can quickly lead to problems.

Last but not least there are attempts like Linspire’s CNR or the OpenSuse build server. Both are quite similar in the regard that they both try to build several different distribution packages for each program. The OpenSuse build server even creates native repositories for each piece of software. However, both have the same problem: they are central server based.
Another problem they also share with the Checkinstall attempt is even worse: they can only support a basic set of distributions and therefore exclude all other distributions (and therefore all innovative but small distributions as well). Every additional distribution especially with a new package format would add another level of complexity.
Even if you would follow that way of providing binaries you would face the problem that a small group of people would have to decide which distribution is “important” and which not – such a single position of power inside the entire Linux community could run into trouble.

The theory of the perfect solution

Therefore the only solution is a system which can interact with the native package format somehow. When there is a way to register files within the native package manager, conflicts are detectable. The LSB has the same position: Ian wrote an article about that topic, Software installation on Linux Part 2. Although his focus is on proprietary software developers and mine is on FLOSS developers the arguments are equal for both groups. Actually the situation described by me is even worse because I have my focus on groups who have not enough money to provide several different packages for different distributions, like Skype for example has.

As you can see from this post there is a new initiative to implement an API into the native package managements. The idea is that this API is the same on each distribution and could be accessed by an installer to register files, scripts and in future versions maybe even dependencies. The advantage is that the installer would not need to know which distribution is underneath the API since the API can be implemented by each distribution and would be the same everywhere.

However, nothing has happened yet an the e-mail list is already silent again. I tried to get more information from some of the RPM developers about that, but still wait for answers. I also logged into the rpm-irc channel, and asked around – the only answers I got there were very, very negative.
Still, Ian is very positive about that topic and just asks for a bit more patience:

Paul Nasrat (Red Hat), Michael Schroeder (SUSE), and Seth Vidal (Fedora/yum) were all at the Packaging Summit, and they were all willing. Give it some time. These things don’t happen overnight.

I am not as hopefull as Ian is at the moment, but I will address that problem in a later article. For this time I will just follow the argument that we need to interact with the local package managers: there is currently only one tool available following this path more or less: InstallJammer.

InstallJammer

InstallJammer is the “newcomer” of the alternative package generators. I write newcomer because I haven’t heard of the program until I read the linux.com article although the program was started 5 years ago… Anyhow, I asked the developer Damon Courtney some questions and he kindly responded. Therefore this section is a bit more detailed since I have a better in-depth view.

InstallJammer was created out of the need to have a possibility to provide users an easy way to install a specific software.

That was one of the biggest reasons I wrote InstallJammer. I was
actually in the process of writing a game when I started thinking about
how I was going to distribute it. The common idiom would have been an
installer on Windows and a .tar.gz on various UNIX platforms. I really
HATE distributing software with a tar or zip file. It’s ugly, and it
doesn’t do anything to help the user. So, I started work on a little
installer to do the work for me. As time went on, I spent more time
working on the installer than the game, and here we are. That was over
5 years ago.

Currently InstallJammer provides a self executing binary which can create dummy packages for the native package manager dpkg and rpm. These even go so far that removing the rpm or deb dummy the remove process of the InstallJammer package is called. However, the dummy packages do not contain any file names. Also, they do require the native package manager build tools on the users machine.
However, Damon told me that he would love to add the ability to register files with the native package manager:

I would absolutely LOVE to be able to support the adding of files to
the package manager databases, and I would definitely like to extend the
support for other native package managers.
[...]
Adding files in dpkg is actually a pretty easy leap because the dpkg
file list is just stored in a text file. I don’t have to muck around
with a specific format or anything tricky. RPM is a lot harder because
the files are stored in a database, and the structure of that database
is not documented or supported for future releases.

Damon also mentioned that the LSB solution of a API provided by the original package manager developers would be the optimal solution – he would like to avoid trying to implement something by his own. Due to the fact that an rpm interaction is quite difficult it is unlikely that the next InstallJammer version will integrate such a thing, however we might see a dpkg integration. Of course, if the rpm initiative takes of we even might see much more integration.

As you see InstallJammer is yet very promising, but doesn’t realize the perfect solution yet. In this regard it strongly depends on the decisions of other people/projects, so we have to wait for future versions atm.

Some final words

You can clearly see now what I see as the only possible solution: a unified binary installer. And that is hot stuff – there are quite some people around who do not like something like that for several reasons. If you also have objections please hold them until I posted my “arguments” post. It will be dedicated to the different pro and contra arguments.

About these ads

10 thoughts on “Linux Software Installation, Part IV: Solutions


  1. Paul Nasrat (Red Hat), Michael Schroeder (SUSE), and Seth Vidal (Fedora/yum) were all at the Packaging Summit, and they were all willing. Give it some time. These things don’t happen overnight.

    No Debian guys? Or does Ian still count himself?

  2. Ian answered to a post of mine asking questions about the rpm situation therefore he mentioned only rpm guys.
    The summit had much more visitors, including Michael Vogt (apt/Ubuntu), Joey Hess (alien) and so on.

  3. InstallJammer gives far too much power to developers to be a serious contender. If you look at software installation on windows even highly reputable (I prefer not to name names but I could)ISVs take lots of liberties. A favourite seems to be adding the app to autostart, weather there is a reason for that or not. Adding something to the system tray is also popular.

    As for integrating with the package manager: This is not required at all, although a lot of people would want it. To cut the package manager out of the picture you only need to do two things:
    1) not-manage dependencies, just ship them in the package and use “LSB version X” as the only external dependency.
    2) Install to a part of the filesystem a package manager won’t touch, ever, /opt/ and /home/user/ both apply.

    The Linux Foundation installer will do both although it dose plan to integrate with the package manager, as far as I can tell that’s just to provide a single place to manage software, I could be wrong though.

  4. I disagree that InstallJammer is too powerful for the developer. I think that is what’s really needed here. Dpkg and RPM both allow shell scripts to be run at several points during the installation process, and they both require root to install. How is this any less powerful?

    In fact, InstallJammer does not require root at all unless the developer actually says he requires it. And, of course, it’s always up to the user whether they choose to give that kind of access. You put a lot of trust in the developer anytime you install software by any method.

    Personally, I never put install a desktop shortcut or any other feature like that without first asking the user if that’s something they want. I hate when installers assume I want their app on my desktop or my system tray. But then, that’s who I am as a developer, and I apply the same courtesy to my users.

  5. The diffrnce between Install Jammer and dpkg/RPM is that time and again the people installing to repositories have proven they are trustworthy. On the other hand if you look at Windows the ISVs have proven that they cannot be trusted. Desktop shortcuts are the least of the liberties taken, look at starforce http://en.wikipedia.org/wiki/Starforce or the sony rootkit.

    And then, if we make the assumption that were talking about end user desktop software. Why often do you need to execute a shell to install it? Thats not a root shell, just any shell? The only example I can think of is when you want to intergrate you’re software with a web-browser, like a media player. Unless you can come up with many more cases why a shell is needed then why on earth allow it? A locked down installer would send a clear message that on Linux you can’t do whatever the hell you want.

  6. On a first look Installjammer looks to be a nice way to add the functionality to native package installers that I have found to be missing. For example, usually when one uses RPM/YUM to install some software there is very little user feedback. Even a ‘run after install’ function is missing (Use Case: I’ve just searched through the repositoy, found the software I want, installed it, now I have to search through the menus to start it and read all the docs to use it. I am just an average user who will read the docs only when I really have to).

    What is greatly missing, at least with RPM installs, is a clean way to ask useful questions of the user perhaps with some explanation, change settings based on those questions and present a summary screen at the end of the install (and also drop a text file of those changes somewhere for future reference).

    Repositories are a great way to store/organise thousands of packages and make them available with dependancy resolution etc but there is still no neat way to install a group of packages making configuration changes as neccessary and letting the user know about them. For example when one installs mysql on Fedora/Centos you should, during install, be able to set a default password and select whether you want mysql to start when the machine starts.

    Additionally having tried to install some complex Java apps (Compiere, Adempiere, open for business) I find that leaving the developer to do the work of guessing what the user wants to do in every use case leaves the installation process far behind the software. Adempiere does a good job of trying to fix this but the install is still complicated and prone to *Just Not Working*. Being able to layer some user controlled/user defined pre- and post- configuration tasks over the binary package installers is a huge gap in the installers in the the linux world and is sorely missed.

  7. One package manager that seems to be missing here is Smart Package Manager. It attempts to become a single frontend for multiple package managers ( http://labix.org/smart ). This is not to say that you can use apt repositories on Fedora/yum based Linuxes. It just allows you to use one frontend on all linuxes with Smart taking care of the backend repositories transparently and using apt/rpm etc as neccessary. It meets the use case of ‘ I want to learn only one application installer on all the different linuxes I want to use. I dont care about the details. I am an average user with limited time on my hands. ‘

  8. The first thing you mention is partly due to design – the package management does not expect a specific user but installs for all of them, therefore a “run after installation” simply is impossible since you don’t know which user to take.
    The same is true for displaying additional information to the user – this cannot be done after the install process because the install process is totally independent from the user – or any user at all.

    However, this could partly be fixed by a semi-intelligent menu like Windows does it: the menu informs you if there were new applications installed, and points them out. This is at least easier than searching menus.
    I think that would be the best way of targetting this problem.

    About things like “activate on startup” – rpm could become more interactive by post-install scripts. This is possible. However – but that might be more a question of the taste – I would prefer having meta-packages like “activate-service-xyz-on-startup.rpm” or similar.

    I wonder if/how these questions will be discussed/addressed at the next Linux Foundation Collaboration Summit – because these are exactly the questions the enterprise has, I think.

  9. The packages/package manager is probably not the best place for user interaction as packages need to be fully independant with no interaction needed. For example for ongoing updates you wouldn’t want the user to have to input data for packages being updates.

    This is why I like Installjammer (at least from a first look). Multi-distro support (incl Mac and windows) is a key feature (as it is in smart Package Manager) that should be at the top of everyones list.

    At the moment if you are looking for an application to complete a task you either have to know about it beforehand or you can read the (sometimes too brief) note in the package manager and take a best guess at an application which might fullfil your needs. Install, read the docs, look at the web page etc etc.

    Installjammer can wrap a bunch of packages up, install them from the repositories (using yum or apt or whatnot) and configure them for you after asking some relevant questions. at the end it can provide some links to websites and give you a summary of what was installed and actually launch the application (yes much like windows installers do).

    This meta/human information is probably not best located in the RPM or apt package. It should have a gui frontend and be easy to use. It should also be the same on as many distros as possible. Again, ‘normal people’ don’t always want to learn to do things multiple ways.

    A nice series of articles btw. Very useful.

Comments are closed.