Slashdot Mirror
Gentoo Linux Rethinks Package Management System
YOU ARE SO FIRED! writes "In an effort to conform to the LSB standards, Gentoo Linux will be adopting RPM as the standard form of package management in portage 2.1. More information can be found in the Gentoo weekly newsletter. I'd surely be fired if I would've proposed such an idea!"
http://marc.theaimsgroup.com/?l=gentoo-user&r=1&w= 2
Check the above link for some of the gentoo-user mailing list archives - discussion started a few minutes after the newsletter went out. Common consensus is that it's April Fools - killing the package management system that makes Gentoo unique and requiring X is just too big a step to make without any discussion on the gentoo-dev list. Kurt did a really good job on this one if Slashdot bit!
1. It's a joke. (Look at the calendar. Don't believe anything you read on slashdot in the next 24 hours).
..., get home from work exhausted the next day, look for that package, find a few rpms compiled for a different distro, architecture, gcc version, or rpm version, scream in disgust, and then switch to Debian or Gentoo.
2. You obviously know not of what you speak. RPMs are more complicated than Gentoo ebuilds or debian debs.
With Gentoo you type:
# emerge enlightenment
You don't have to know anything about C, C++, Python or even shell scripting. All you have to know is your architecture and the optimizations you want (and the detailed docs are very newbie friendly).
with debian type:
# apt-get install enlightenment
Either distro will then install E, X, and all required libs/programs.
Both distros have centralized package repositories (free of charge) that contain everything I've ever needed, tested for full compatibility.
With rpm, you find the package, download it, type the rpm command, get an error about libWhatever.X.Y.Z.so being required, spend hours figuring out what package has libWhatever.X.Y.Z.so, go to bed three hours late, because you were looking for the package,
There is a thread in the Gentoo forums about this.
"I filter at +6, and have yet to miss out on an important comment." (#822545)
With debian and gentoo the package format and package manager are highly coordinated. /usr/portage contain all depenencies. I forget whether debian includes them in apt's database or in the actual deb file, but apt-get install has never failed me.
An rpm doesn't include a list of all rpms it requires, just libs, and neither does the rpm database.
The ebuilds in
Having some other person be able to run the server that redhat should give access to for free doesn't help. That server is pretty useless unless it's housing the latest packages all tested for integration, like debian and gentoo. And who's running it? I feel pretty safe getting files from debian.org or gentoo.org, but some_guys_home-grown_redhat.com doesn't inspire confidence in me.
Rpm was never designed for upgrading. Redhat's idea of an upgrade is buy the next version and install it.
A debian box can do an entire upgrade (including glibc) without having to reinstall or even reboot. The only thing that requires a reboot is a kernel upgrade, so you can run the new kernel.
I'd suspect that gentoo can act similarly. And I'll find out when the next major revision of glibc comes out.
Sounds like you want something like Zero Install. It uses the globally unique nature of the Internet's DNS system to remove the need for a central package database, allowing packages to be fetched (and cached) as they're needed, so you never install anything you don't use.
There are no dependancy issues, because applications link to resources by URI, so the system always knows where to get missing files from.
And you don't need to be root to 'install' stuff, because it's just a high-speed network cache, so all users can install stuff easily and safely, and you don't get buggy running-as-root postinst scripts bombing out and messing up your system like on Debian, etc.
And April 1st was probably a bad time for me to announce this ;-)
The main difference is not in the packaing system per se, but in the adherence to common policies that allow many packages to coexist peacefully. Debian is huge, and at release nearly all of it works out of the box, and on 11 architectures. Without binary compiles, a lot of problems would not be found - approximately half the bug fixes are discovered during the multiple-architecture autobuild process. Source may build a package on a developer's machine, but subtle dependencies may prevent it from compiling and running elsewhere. By the time a .deb is uploaded and promoted to testing or stable it's gone through quite a guantlet already.
.debs can be unpacked with normal unix tools, config file handling, etc. It's arguable whether these are better in RH or Debian, but the last project leader who suggested changing fled before being kicked out (hi Bruce :). Debian does not encourage getting packages from third parties (rather join Debian and upload a native packaging), so binary package compatibility is not really a desireable feature anyway. You can, but don't expect much pity when the rpm doesn't work or it craps all over some other package's space and it doesn't make use of Debian's many unique features (menu, doc-base, alternatives, environment-free defaults, ...) .deb in the particular Debian release. rproxy can reduce this to just the diffs from a previous download.
Having such a common set of packages makes constructing an automatic dependency resolver easier, which is why apt-get often works better than it's redhat cousins. It also means you seldom need to go outside the package manager and risk losing accurate configuration and dependency information. If something you need isn't in Debian, consider packaging it for yourself to keep your package DB accurate, and then join Debian to become a developer.
There are fairly small differences in the actual format that Debian doesn't want to give up, refinements in the way inst/preinst scripts fire, the way
apt-get does download the Packages.gz files, which are basically concatenations of the control files for every