Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Linux Software

Gentoo Linux Rethinks Package Management System 300

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!"
This discussion has been archived. No new comments can be posted.

Gentoo Linux Rethinks Package Management System

Comments Filter:
  • April Fool's (Score:3, Informative)

    by Mr.Ned ( 79679 ) on Tuesday April 01, 2003 @12:40AM (#5636078)
    http://marc.theaimsgroup.com/?l=gentoo-user&r=1&w= 2 [theaimsgroup.com]

    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!
  • by kwiqsilver ( 585008 ) on Tuesday April 01, 2003 @01:12AM (#5636255)
    1. It's a joke. (Look at the calendar. Don't believe anything you read on slashdot in the next 24 hours).
    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, ..., 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.
  • Gentoo forum thread (Score:3, Informative)

    by nacs ( 658138 ) on Tuesday April 01, 2003 @01:34AM (#5636355) Journal
    There is a thread in the Gentoo forums [gentoo.org] about this.
  • by kwiqsilver ( 585008 ) on Tuesday April 01, 2003 @02:13AM (#5636498)
    With debian and gentoo the package format and package manager are highly coordinated.
    An rpm doesn't include a list of all rpms it requires, just libs, and neither does the rpm database.
    The ebuilds in /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.
    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.
  • by tal197 ( 144614 ) on Tuesday April 01, 2003 @07:02AM (#5637121) Homepage Journal
    So you try to install lynx and find perl is a dependency. wha? ok, so you install perl. You don't really have space for it on this box, but hey, maybe it will come in handy. But the perl rpm says a dozen or so perl modules are dependencies. huh? Those damn things are optional, goddammit.

    Sounds like you want something like Zero Install [sf.net]. 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 ;-)

  • Re:April Fool's (Score:3, Informative)

    by klieber ( 124032 ) on Tuesday April 01, 2003 @08:58AM (#5637371) Homepage
    Thanks. I thought so, too. :)

    If you thought the discussion on gentoo-user was amusing, you should have seen the flamewar on #gentoo. I am amazed and astounded at how many people fell for this joke. Of course, I speak with inside knowledge of the project, but the idea that we would migrate to RPMs for our package management format is simply not in the realm of possibility. I assumed most people would realize that, too. :)

    Then again, we did go to great pains to research the LSB to come up with support, albeit tenuous, for our arguments.

    --kurt
  • by Anonymous Coward on Tuesday April 01, 2003 @03:25PM (#5639704)
    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.

    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 .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, ...)
    apt-get does download the Packages.gz files, which are basically concatenations of the control files for every .deb in the particular Debian release. rproxy can reduce this to just the diffs from a previous download.

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Working...