Too much choice [LWN.net]

Too much choice

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

I could not agree more! I did not know anybody else thought this way! Every time I think about distributing software for Linux I want to scream!

I have developed a lot of software for Linux as an ISV, and I can say that packaging is the worst part of making software for Linux. khim, add the VirtualBox download page to your shame list.

I have packaged plenty of software for all Linux distributions and for Solaris. I understand all the technical issues involved, and I understand how rpm/yum and deb/apt is technically far more advanced than the Windows. But the reality is, it is trivial to install third party software on Windows. This is one remaining area where Windows just works and Linux is woefully inadequate from the user perspective.

I think there are several things to think about in order to reach a good mix of the advantages of Linux distribution packaging and Windows "mu-packaging" (i.e. no packaging or minimalist packaging).

Well-done packages for Linux are advantageous. Besides being impossible with non-free software, some components (LDAP, most servers, logging) are best done by experts who understand the big picture of the distro.
But, distributions are also hamstringing themselves since in practice all software must be packaged for each distro in a process ISVs consider tedious and time-wasting.
The current Linux software distribution system is centralized and assumes dumb nodes (ISVs) on the edge of the network, with smart hubs (packagers) in the center. This is wrong. To scale to be a great software platform, we need a decentralized distribution system where smart edge nodes can get software to all their users with minimal effort.
Windows ISVs consider their software packages (setup.exe) as code, Linux packages consider their software packagages (something.rpm) as data. In reality, both are code and data. The difference is perception.

FWIW, my favorite package system is: Solaris. Conceptually, packages are just tarballs with the standard preinst hooks and basic dependency tracking. Not too smart, not too dumb, and convenient for ISVs

(Log in to post comments)

Too much choice

Posted Jan 20, 2008 11:15 UTC (Sun) by jhs (subscriber, #12429) [Link]

Linux packaging.  Notice how Windows and OS X require one entry each, and Linux gets
twenty-one, plus a walkthrough for installing through apt.

Too much choice

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

That is actually also a kernel API/ABI-related problem.  If you try them out, you will find
that many of the rpms and debs on the web page will install on different distributions (in
fact, you could get by with one of the debs and two or three of the rpms).  But since each
distribution comes with different kernel versions, the distribution packages also contain
pre-built kernel modules so that the people installing do not need to build their own.

If someone does install a package which does not contain modules for their kernel though, and
if they have gcc, kernel headers and friends installed, the right module will be built during
the installation.

Too much choice

Posted Jan 20, 2008 12:03 UTC (Sun) by jhs (subscriber, #12429) [Link]

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)?

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.

Too much choice

Posted Jan 21, 2008 3:50 UTC (Mon) by salimma (subscriber, #34460) [Link]

That is what DKMS is for, surely.

Too much choice

Posted Jan 21, 2008 6:17 UTC (Mon) by michaeljt (subscriber, #39183) [Link]

DKMS is something I hear of once every six months.  Is it really in use?  And if so, how much
overhead does it mean for end users?

Too much choice

Posted Jan 22, 2008 0:40 UTC (Tue) by salimma (subscriber, #34460) [Link]

It's used by at least one popular third-party repository for Fedora (FreshRPMS), and since it
was developed by Dell, presumably the repositories that Dell host to support their Linux
machines use DKMS for kernel modules.

The only overhead is that you need a compiler and the kernel headers installed. (Oh, and on
Fedora, right now, it cannot clean up old modules when the corresponding kernel is removed. On
Debian/Ubuntu this works, and they're working to port the fix)

Too much choice

Posted Jan 21, 2008 4:24 UTC (Mon) by jhs (subscriber, #12429) [Link]

I think these are all great points.  Package frameworks are highly evolved, while package
developers are talented and invaluable.

The current package system is great for core components and for tight integration.  Where
there is a problem yet to be solved is with end-user applications which are not (yet) core
components of the distro.  Plenty of developers write end-user software that is an endpoint in
the dependency graph.  These developers want to reach as many new users as possible, so it
would be great if they could trivially distribute software on the major distros.  (Again,
dependencies are only one issue: boot scripts, on-line documentation, iptables, inetd, cron,
and other components must also be dealt with.)

Much free software is built with Autotools to make its *source* portable on many platforms.
But at the other end, it's not so easy to turn compiled binaries into packages for each distro
and architecture.  Ideally, end-user software could be distributed in "good enough"
wizard-built packages that allow people to try the software out.  If it looks like something
is the new killer app, and Distro X decides to bundle it in their distro, then at that point
they can work on their custom packages, ideally in cooperation with the upstream developer.
It's all free software, of course!

Too much choice

Posted Jan 21, 2008 12:25 UTC (Mon) by robilad (guest, #27163) [Link]

Usually, if something is the killer app, someone volunteers to package it for their favorite
distribution. You can encourage that as a pro-active upstream, and keep your packagers updated
of important changes ahead of releases, for example.

Too much choice

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

autotools is almost unneeded now, the staggering differences among Unix systems are very much non-existent among Linux distributions. And, given the right tools, building one's own RPMs is not that hard. Sure, following the packaging guidelines for one's distribution and creating a package acceptable for official inclusion is another pair of shoes.

Too much choice

Posted Jan 26, 2008 11:46 UTC (Sat) by talex (subscriber, #19139) [Link]

All the problems you listed also apply to centralised systems. e.g. if I create a .deb for Ubuntu that depends on other Ubuntu packages, what stops Ubuntu from updating their packages and causing exactly the same problems?

"You need to ship and support every (broken) version of a dependency someone has ever used as ISVs don't upgrade their dependencies unless they really, really have to,"

I'd say this problem only applies to centralised systems. e.g. I might need to ship a fixed libpng with my Ubuntu package, but not with my Fedora package. In a decentralised system, I'd just link against the known-good Fedora version for both.