2008-06-29

Woes of Linux packaging and installers

I commented under a very good article:

http://loupgaroublond.blogspot.com/2008/06/do-we-really-need-another-packaging.html

1) You wrote:
In creating nearly all packages, there is always some amount of shell scripting that needs to be done.

Yes, this is historically what is being done. However the more I think about it, the more problematic I see it. Why are there during installation things that has to be done by shell scripting??? What are these things?

Installing a package means to copy its files in the right places (binaries, docs, images, launchers, etc.), create/update config files, restart services. All these things could be done by the installer, and the pre-inst and post-inst scripts IMO hide the deficiencies of the package manager and/or package format.

For Java there is the "ant" tool, and this way for compilation the tested, proven and versatile (but old) makefiles are not needed. And the ant's build.xml file is, well, XML. Even more, ant is extendable by providing it with new "actions" so it it not limited to a single set of XML tags. This lets me have a confidence it would be doable to use XML for package management, so please don't spread misinformation and prejudices here.

Even more:
Many packages require some form of post-install and pre-uninstall scripting to be done. The most universal method for doing this on any distribution is a script.

Yes, you're right. However, if the package managers would run such a script providing it with the settings like paths to config files, description of package dependencies, and other things that differ between distributions today - this would be an even more powerful mechanism. And at this point I would agree that there is a place for shell scripting (which I like and use quite often in my everyday work).

2) You mentioned a myth:
The user should be able to get a package from just about anywhere, and it should run automatically on their Linux system.

I fail to consider this a myth. Either we want uniformization of Linux environment or we don't. Either it is a good thing to expand Linux penetration of the market or it's bad. If these goals are to be met, this is one of the means to achieve these goals.

Why do distributors and distributions exist? Because people have different views on how to do things. Different gcc and toolchain versions, different compiler settings, different locations of config files (think: apache2), different package formats. If there was some common ground in a form of installer API, no need for pre-inst and post-inst scripts and to some extent uniformity of the OS environment, all the above differences would become less important.

Maybe it's time to really think about more cross-distributions standardization?

3) However:
Trying to funnel everything down through some common layer at the bottom really reduces the chances for big innovation to happen.

And here I agree with you 100%. So in fact I'm not completely sure what to do w.r.t. software packaging in Linux. But uniform approach to this problem and uniform solution would surely bring commercial world to Linux. So they would be able to package their software once and it would run in almost every distro. One thing remains to be answered, whether this is really a goal that we would like to reach?

No comments: