Too much choice [LWN.net]

Too much choice

Posted Jan 20, 2008 12:03 UTC (Sun) by jhs (subscriber, #12429)
In reply to: Too much choice by michaeljt
Parent article: Fedora developers on PackageKit

That's a good point, and I'm sure a product like VirtualBox is particularly sensitive to
kernel API/ABI changes.

Kernel developers don't want a stable API and ABI, and I think they make their case well.  But
there is still a problem that distributing software for Linux is hard, and the whole community
suffers because of that.  For free software projects (or at least software distributed in
source form), the changing APIs and ABIs aren't the only problem: boot scripts, SELinux,
firewalls, mountpoints, authentication back-ends, and dependencies (to name but a few) must
all be considered when packaging software for Linux.

Again, I don't think I have the answer, I just think it needs broad discussion.  But in my
opinion, a package-building wizard that works for >= 90% of ISVs is sorely needed.  But to be
successful it will probably require development and maintenance from experts from all the
major distributions.  We need a way to get all the benefit from the package systems (updates,
dependability, maintainability, scalability, dependency tracking, authentication, etc.) but
still make it a no-brainer for (most) ISVs to ship their software on "Linux."  We need to shed
ourselves of this bottleneck that is packagers for every distro.  Why can't third-party
software catch on among the masses and *then* Canonical decides to make *their* own package to
make it really sharp and integrated (probably brown in color of course)?

(Log in to post comments)

Too much choice

Posted Jan 20, 2008 14:51 UTC (Sun) by michaeljt (subscriber, #39183) [Link]

I think that my current packaging ideal would be as follows.  The package developer creates a
source meta-package using some reasonably easy-to-understand system which can build to (source
and binary) rpm, deb and similar targets.  The developer would of course still need to do a
build on a few different systems (which could however be virtual machines or chroot jails) to
get a set of packages which will install on most distributions.  Then the people who would
otherwise have packaged the software for distributions can simply liaise with the developer to
make sure that the meta package complies with any distribution policies.  If source is
available, distributions could do automatic rebuilds of the source debs and rpms when they add
the software to their repositories.

I am planning on giving something like this a try when I have time.

Too much choice

Posted Jan 24, 2008 21:02 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Each distribution has its own "ABI":

Names of "system" accounts and groups
Exact versions (and configuration) of base libraries
Setup for starting/stopping services (see this LWN issue for a discussion of some different alternatives)
Even if a traditional SysV runlevel-based system is in place, runlevels have very different meanings
Kernel versions, and their small (and not-so-small) differences in behavior

Too much choice

Posted Jan 25, 2008 8:49 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

This is true, but it is still possible to produce a package which will work just about
everywhere (take a look at the VirtualBox "all distributions" installer for a proof of
concept, putting aside the merits and weaknesses of the implementation).  It is certainly
quite a bit of work, but that is at least in part due to lack of experience in the field - I
think that someone who has done it once would be able to do it again with much less effort.