To view parent comment, click here.
To read all comments associated with this story, please click here.
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.
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.
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.





Member since:
2006-11-24
YES, there are.
http://en.wikipedia.org/wiki/Package_management_system#Examples
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.