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 202121
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: B.A.D idea
by Terracotta on Tue 16th Jan 2007 11:35 UTC in reply to "RE: B.A.D idea"
Terracotta
Member since:
2005-08-15

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[3]: B.A.D idea
by tom1 on Tue 16th Jan 2007 12:49 in reply to "RE[2]: B.A.D idea"
tom1 Member since:
2005-07-12

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.

This is exactly why you need a decentralised system: your example is a centralised system failing to cope with packages from two different distributions! It's quite possible to create a system that would handle this situation fine.

Reply Parent Score: 1

RE[4]: B.A.D idea
by Terracotta on Tue 16th Jan 2007 15:38 in reply to "RE[3]: B.A.D idea"
Terracotta Member since:
2005-08-15

The reason it fails is not because it's a centralised system, it's because you're trying to install a package created for one distribution on another distribution. If that distribution differs too much from the distribution it was created for it might not work. It's perfectly possible to distribute .debs in a decentralised way (opera does it like this). It's a bit more work for opera, but well it's quite easy to install opera on an ubuntu/xandros/mepis/debian/suse... system.
I'd rather see more .deb, or .rpm packages on website than .autopackage packages, for those who insist on installing a program by searching the net and downloading it from a website.

Reply Parent Score: 2

RE[3]: B.A.D idea
by draethus on Tue 16th Jan 2007 14:49 in reply to "RE[2]: B.A.D idea"
draethus Member since:
2006-08-02

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.

Maybe that's because on Windows backward compatibility and binary compatibility are solved problems, on Linux they're not.

Write and compile a program on Windows Vista using only functions available in Windows 95, then take it to a Windows 95 box, and it will work.

Now compile on glibc 2.4 using only ANSI C functions, take your program to a box with glibc 2.3 and it will fail to start, even though all the functions you use are available. And that's not even going to horrors like thread-local locales, where it won't even work on another libc of the same version compiled without that option, and Fedora Core 6's GCC's DT_GNU_HASH, where unless you compile with special flags, AFAIK your program doesn't even run on any other distro.

It's not that people want the latest and greatest - currently the only reliable way to get unpackaged software installed is to compile it, and ISVs want to write software once and have it work on every distro for all time.

If you know something I don't, please elaborate.

Reply Parent Score: 3

RE[4]: B.A.D idea
by Terracotta on Tue 16th Jan 2007 15:23 in reply to "RE[3]: B.A.D idea"
Terracotta Member since:
2005-08-15

Well I know for one that backward compatibility is not solved in the windows world. For example Navision (a MS product), can not run on windows Vista.

Backward compatibility has also it's drawbacks in speed: as in being forced to keep all drivers ever created to be supported, i.e. USB-drivers in windows vs the fasted drivers for USB in linux.

Compatability on binary level is disease that has more drawbacks than it is good for and is something that the open source world circumvents quite well: on source level.It should not be introduced in the open source world.

Reply Parent Score: 2

RE[3]: B.A.D idea
by Lambda on Tue 16th Jan 2007 16:51 in reply to "RE[2]: B.A.D idea"
Lambda Member since:
2006-07-28

No, just the opposite. Ubuntu and Debian incompatibilites are perfect examples of a subpar packaging system. Scroll (depending your threaded view) up to find links on the Conary packaging system. Fine-grained versioning would seem to solve these incompatibility problems.

Reply Parent Score: 2