Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Too much choice

Posted Jan 20, 2008 16:30 UTC (Sun) by robilad (guest, #27163)
In reply to: Too much choice by jhs
Parent article: Fedora developers on PackageKit

Decentralized systems for shipping interdependant binaries don't work in practice, as sweet as
they sound in theory. 

* you get metadata drift, 
* you get binary incompatible dependencies due to build time differences,
* you lose any opportunity to QA the distribution as you no longer know what your dependency
graph looks like, 
* 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,
* etc.

DLL hell, RPM hell, JAR hell, the phenomenon has many names.

The only reason why Debian, Fedora, ports, or even CPAN scale so well is 

* they are centralized
* they are source code based

(Log in to post comments)

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.