Linked by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC
General Development In the Free and Open Source communities we are proud of our 'bazaar' model, where anyone can join in by setting up a project and publishing their programs. Users are free to pick and choose whatever software they want... provided they're happy to compile from source, resolve dependencies manually and give up automatic security and feature updates. In this essay, I introduce 'decentralised' installation systems, such as Autopackage and Zero Install, which aim to provide these missing features.
Thread beginning with comment 202060
To read all comments associated with this story, please click here.
B.A.D idea
by theGrump on Tue 16th Jan 2007 03:30 UTC
Member since:

sounds like a lovely way to destroy your system. and are there really that many package management systems in use? from what i can tell, 80% of linux users are likely using a rpm or deb derived package platform. those who aren't really only have one valid counterargument - the desire to build all code locally a la gentoo.

these "generic" packaging projects were and are non-starters, even if they could create a system that makes sense, utilizes your hardware properly (not one size fits all) and does not destroy your install, no one is using them anyway

Browser: ELinks/0.11.1-1.2-debian (textmode; Linux 2.6.18-3-686 i686; 91x34-3)

Reply Score: 4

RE: B.A.D idea
by raynevandunem on Tue 16th Jan 2007 03:38 in reply to "B.A.D idea"
raynevandunem Member since:

YES, there are.

Furthermore, as in the case with Ubuntu and Debian, a distribution with the exact same PMS as the next distro can still be incompatible with that other distro.

Reply Parent Score: 4

RE[2]: B.A.D idea
by Terracotta on Tue 16th Jan 2007 11:35 in reply to "RE: B.A.D idea"
Terracotta Member since:

Ubuntu and Debian are the perfect examples showing why decentralised packaging is a BAD idea. If two systems that are so closely related to each other as they are, using the same packaging and installing system, succeed in creating incompatible binary packages, how should a decentralised packaging system solve binary incompatabilities between let's say Red Hat and Debian.

The problem this article about decentralised installation tries to solve is a closed-source problem. If an open-source programmer can't get his open source program into the main tree of distributions, he can provide .deb and .rpm packages. The user can install them quite easily (richt click: install package (in kubuntu and ubuntu that is)), and i.e. apt-get will search for dependencies on the centralised system. It's more work for the maintainer in the beginning (and a lot of work for closed-source programmers to provide .debs and .rpms for all distro's, Opera seems to like this way of working though), but afterwards when distributions start packaging his program he'll get more peer review by actual programmers who compile and support his packages.

This week seems to be about porting problems from the windows world to the FOSS world. First backward compatibility and now binary compatibility. They are only problems to people who want the latest and greatest.

Reply Parent Score: 3

RE: B.A.D idea
by butters on Tue 16th Jan 2007 04:41 in reply to "B.A.D idea"
butters Member since:

Like the other poster said, there is a difference between package format and package compatibility. You might not realize how similar .rpm and .deb files are to one another. In fact, most of the spec is identical.

The differences lie in package management and package compatibility. For example, we see that rpm has lots of different management systems: yum, urpmi, and yast come to mind. The APT equivalent of rpm is dpkg, but people simply refer to the Debian-derived system as APT because it is more-or-less the de-facto management system for dpkg.

Further, distributions often change the dependencies, add/remove patches, and even change the names of packages they port from other distros to play well on their systems. The name of the Xorg server package, for example, is different on many distributions, and each distro uses different distro-specific patches.

Could this be made simpler? Yes... but the distros hide this complexity from the user. It is mainly more complex for the distributor and its packagers instead of for the end users.

Speaking of which, this whole distributed vs. centralized package management debate represents a tradeoff--shifting work between upstream and the distributor. With distributed packages, the burden is on the upstream developer to get their package working on as many distros as possible. With centralized packaging, the burden is on the distributor to get as many upstream packages to work on their distro.

Guess what? Developers hate packaging! They want their job to be done as soon as their source tree builds and runs properly. Distributors, on the other hand, are essentially packaging machines. Packaging is what they do best. Why not leave things as they are? Let the developers code, and let the distributors package.

Reply Parent Score: 5

RE[2]: B.A.D idea
by de_wizze on Tue 16th Jan 2007 05:10 in reply to "RE: B.A.D idea"
de_wizze Member since:

Because the Distributors sometimes take long to package. What it should is as simple for developers to package that properly running source tree as taring the folder. Notice that what is described in the article simply generates instructions as to what is provided/needed in terms of files and actions.

Reply Parent Score: 3

RE[2]: B.A.D idea
by draethus on Tue 16th Jan 2007 09:22 in reply to "RE: B.A.D idea"
draethus Member since:

Guess what? Developers hate packaging!

Yes, mostly because they have to build 1 package per version of each distro. On Windows, they build one package alltogether.

Distributors, on the other hand, are essentially packaging machines. Packaging is what they do best.

Not by a long shot. A frightening amount of packaging is done by people who don't know what they're doing. Wine, for example, comes with wineserver, a per-user server that handles things like inter-process synchronization, which is started on-demand by wine and exits when wine itself exits. A while back, some distro put wineserver in an initscript (it's a server, right?) and tried to run it on startup, as root!

Like autopackage put it, it makes no more sense for a distro to do packaging than for them to do artwork and GUI design for the app.

Why not leave things as they are? Let the developers code, and let the distributors package.

Developers need feedback from users, and getting feedback from a version you released 6-12 months ago is worse than useless.

Distributors produce one package for one version of one distro - an absolute vendor lock-in.

Distributors have to put in extra work packaging, testing, dealing with bug reports - and that's for each distro. Tonnes of wasted effort being the middle man.

Making a DEB or RPM is an absolute waste of your time - it works today but not tomorrow, it works on this box but not on that one.

The sad thing is, solutions existed for years now, and end users love them (autopackage website gets 500-1000 hits per day), but distros would rather die than implement them.

Reply Parent Score: 5

RE[2]: B.A.D idea
by John Nilsson on Tue 16th Jan 2007 11:56 in reply to "RE: B.A.D idea"
John Nilsson Member since:

Another approach is to work on a protopackage-format. A standard which sole purpose is to do as much distroindipendent work as possible upstream.

There are a few of those today. We have the autotools, ./configure; make; make install routinte, but it's arguably not very maintainable in the longrun, and not that userfriendly.
Debian is turning into a protodistro.
Gentoo was a "meta"-distribution from the start.

So instead of focusing all effort on how to desing packagesystems to bypass distroefforts (autopackage, klick, zero install, what have you) the effort should be spent on protopackagesystems that makes the lives easier for the user/developer (prosumer) AND distributer.

Reply Parent Score: 3

RE[2]: B.A.D idea
by skroob on Tue 16th Jan 2007 20:11 in reply to "RE: B.A.D idea"
skroob Member since:

> Guess what? Developers hate packaging! They want their
> job to be done as soon as their source tree builds and
> runs properly. Distributors, on the other hand, are
> essentially packaging machines. Packaging is what they do best.

Often the problem is the packagers. They pack the stuff
without any feedback to the developers. First time you
know there is a package for distro $foo is when sombody
sends you a mail about a bug in the package.

Another thing is the delay. When I release something
i want my users to have the new version ASP. Not when
they buy the next CD or hurd is ready.

Reply Parent Score: 2