Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Red Hat Software Businesses Software Linux

Fedora Project to Help Revitalize RPM 334

-=Moridin=- writes "The Fedora Project has announced plans to revitalize RPM, the package manager used by many Linux distros. According to the announcement, 'Job #1 is to take the current RPM codebase and clean it up, and in doing so work with all the other people and groups who rely on RPM to build a first-rate upstream project.' For more information, see the the RPM web site and the new wiki-based RPM FAQ. The issue of RPM's upstream development has been a thorny issue ever since Jeff Johnson, the original maintainer of RPM, left Red Hat."
This discussion has been archived. No new comments can be posted.

Fedora Project to Help Revitalize RPM

Comments Filter:
  • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Friday December 15, 2006 @05:00AM (#17251994) Homepage
    It's been a *long* time since I've used an RPM-based distro. Do RPMs still have a confusing dependancy circle hell? It was perhaps the most frustrating and poorly handled thing about installing software on really any OS I've tried.
  • rpm -uvh apt yum (Score:0, Interesting)

    by Anonymous Coward on Friday December 15, 2006 @05:05AM (#17252022)
    children under 7 must be accompanied by an adult
    each one is able to support more than 14 tons
    and you can really see how big it is
    and together they stretch for almost 1/4 mile
    2.5 times the height of mount everest (the highest point on earth)
    this super-imposed outline will give you an idea of its size
    it's 370 miles wide at the base
    and over 100 feet in length
    but that's 40 miles from the opposite rim
    and over 75,000 feet at the top
    and that figure increases every year
    Rugged, easy-to-clean plastic laminates are used on all the walls and surfaces
    and that figure increases every year
    the floors on which you are walking
    the floors the floors on which you are walking
    the floors on the floors on the floors on which you are walking
    the floors on the floors on the floors on the floors on which you are walking
    children under 7 must be accompanied by an adult
  • Good. (Score:4, Interesting)

    by isometrick ( 817436 ) on Friday December 15, 2006 @05:12AM (#17252072)
    About 1 in 10 times I try to update something in Fedora, I end up having to:

    # rpm --rebuilddb
    # yum clean all
    # yum <whatever I was doing before>
    Not to mention the inevitable lockup when the tray updater is running or the segfaults when I try to interrupt yum during an operation I don't want to finish. Even when it finally works, it takes yum over a minute just to download stuff and work out dependencies before installing or updating.
  • Forgive me, but... (Score:2, Interesting)

    by OneSmartFellow ( 716217 ) on Friday December 15, 2006 @05:49AM (#17252314)
    RPM is really only a packaging standard (ignoring the rpm binary, of course). It seems to me the real issue is not the RPM standard itself, rather the ease of abuse/misuse. In this regard I suggest that the rpm binary be enhanced so that package production is simpler and less error prone. In particular the identification of dependencies. I am continually fighting with various package managers because someone/something has decided that (as an example) when I want to install libusb I must also want to install some GTK based application as well.
  • by Fallingcow ( 213461 ) on Friday December 15, 2006 @06:00AM (#17252362) Homepage
    A better comparison would be dpkg to RPM.

    Apt is a program that automatically resolves dependencies and fetches packages to install, among other things, and it sits on top of a packaging system, like dpkg or even RPM.

    As for dpkg vs RPM, I can only say that I've never had as many problems with dpkg as RPM, especially when installing 3rd-party (unofficial to my distro) packages. I've also had fewer instances of "dependency hell" with dpkg than with RPM, and it's always been easier to fix when I have, but that has more to do with the package and distro maintainers than it does with the packaging system.

    Yum, a popular RPM-based manager (like apt, but specifically for RPM) was certainly a total piece of shit the last time I tried it. Took about 10 times as long to do anything as apt would have for the same operation, and I'm not exaggerating. Maybe it's gotten better, but as recently as a couple years ago it was a huge pain in the ass to use. Apt for RPM seemed pretty good at the time, but I've not used it since. I don't even bother with RPM-based distros anymore, as, of the three systems I've used (dpkg+APT, Gentoo's Portage, and RPM) it was, hands down, the worst. It may be better these days, but then again I've found the recent Fedora builds that I've tryed out make me feel restricted, while simultaneously making me do more work than a modern dpkg-based distro probably would. For some reason, distros based on Debian seem to pick better defaults for newly-installed packages than RPM-based ones do, though I don't know why that is.

    For reference, I've mostly used Mandrake, Debian, Gentoo, and Ubuntu over the years, with lesser but non-trivial amounts of time spent with Red Hat/Fedora and Slackware, and a tiny bit of time with Suse, so any bias in my opinions on the matter may be tied to this, but I really have found that package management was only ever something that I dreaded dealing with when I was on Mandrake and Red Hat/Fedora, and I didn't work with Suse enough to form an opinion on it. Switching to mostly non-RPM distros a few years back made most of my package management woes disappear instantly.
  • by Bastard of Subhumani ( 827601 ) on Friday December 15, 2006 @06:20AM (#17252470) Journal
    I agree. Ideally with an X in the name somewhere.
  • by Jaruzel ( 804522 ) on Friday December 15, 2006 @06:31AM (#17252522) Homepage Journal
    OK, I hear what you are saying... but if MS managed it with MSI (which after 4 years now de-facto for packaging), then surely the Linux community can do it too ?

    *Throws down gauntlet*

  • by Anonymous Coward on Friday December 15, 2006 @06:56AM (#17252680)
    Zero-install is another similar click-and-play system: http://zero-install.sourceforge.net/ [sourceforge.net] Klik is another: http://klik.atekon.de/ [atekon.de] Each has their ups and downs.

    Also you should be able to run the scripts from a file explorer, or set up a "xterm -e" shortcut or something. (can't say for certain since I use the CLI much of the time.)

    Anyhow, personally as someone who likes having a fair bit of control over what's going on in their system, I'm not too fond of any of these automagic systems though. I much prefer when software installs in my regular package management system. I see their use in certain environments but if a program was available ONLY via Autopackage or whatever, I probably wouldn't use it. I don't expect I'm alone.

    To the GP: this is somewhat of a problem with Linux and standards; getting people to agree on "single unified" anything is basically impossible. It is a strength at times, but it means that you can't really count on something in one person's Linux system being available on another's, be it package management tools or otherwise.
  • Just switch to apt (Score:4, Interesting)

    by delire ( 809063 ) on Friday December 15, 2006 @07:06AM (#17252730)
    I've seen enough loyal Fedora/RH users using apt-rpm on their own systems to indicate that a complete transition, ie. replacing rpm's with debs may not be so shocking for a community of $RPMDISTRO users.

    The task of migrating rpm packages over to the deb format would certainly be a massive undertaking, but the popularity and reputation of the Debian packaging system shouldn't be ignored. With the rapid growth of Ubuntu, the interest from historically Linux unfriendly third-parties in releasing packages in a Debian format is hard to ignore. Fedora could benefit from the growth of Debian based distributions, getting a lead on other rpm distros that choose to stick with a troubled package format. They could do what any good distro does these days: focus on offering a quality user experience, choosing the best technology available to fulfill these ends. Package conflict / dependency resolution is a typical reason people turn away from an rpm based distro, even Linux altogether.
  • by Constantine Evans ( 969815 ) on Friday December 15, 2006 @07:13AM (#17252790) Homepage
    Apt is certainly not deprecated in favour of aptitude, as aptitude is a frontend to apt. One could argue that aptitude is superior to apt-get, but it should be noted that apt-get also has autoremoval, at least in Ubuntu. Try apt-get autoremove.

    Personally, I have always used apt-get instead of aptitude.
  • by mpcooke3 ( 306161 ) on Friday December 15, 2006 @07:15AM (#17252804) Homepage
    For that task a universal package format would be better than a universal package manager.

    Unfortunately at the moment most packages don't just contain files and meta data they also have this hacky distro-specific bit that actually runs commands directly on the system. Which is really quite crap.

    For example a sane package format might have something like this to install a font.

    Font: Moo
    Info: truetype, shared
    File: /package/moo.tft
    This would allow any system that supports truetype fonts to install it how it wants.

    But you are more likely to see something like this:

    ttmkfdir -d %{prefix}/%{name} \
            -o %{prefix}/%{name}/fonts.scale
        umask 133
    /usr/X11R6/bin/mkfontdir %{prefix}/%{name}
    /usr/sbin/chkfontpath -q -a %{prefix}/%{name}
        [ -x /usr/bin/fc-cache ] && /usr/bin/fc-cache
    Which is actually a set of commands to install the font on a system with a particular X based font system and directory layout.
  • by Constantine Evans ( 969815 ) on Friday December 15, 2006 @07:35AM (#17252900) Homepage
    The requirements for packaging for Windows is fundamentally different than for Linux. The differences between distributions can be extremely large as Geekmeister mentioned, much larger than differences between versions of Windows, and there are innumerable places where things could vary.

    How would a universal package for apache, for example, know how to set up starting and stopping the service? Different distributions put the scripts in different places, and use different formats and conventions for the scripts. In future versions of Ubuntu, the scripts won't even be shell scripts, and will be handled in a fundamentally different way. The meaning of installed dependencies is also different. USE flags in Gentoo would have to be considered, for example.

    In order to make a package format that would work for everyone, the system would have to resemble autoconf, and check for every imaginable aspect of each system. Like the configure scripts of autoconf, doing so would make installation absurdly slow. The package format would also have to include many versions of files with the same purpose, making the packages very large.

    In short, perhaps such a package format could be made, but it would be inferior to the formats that already exist. In fact, this is the case. Formats like autopackage and klik exist, but they are markedly inferior in terms of stability, reliability, elegance, and usefulness for non-trivial packaging requirements, and usually only used for end-user applications with few dependencies.
  • by g253 ( 855070 ) on Friday December 15, 2006 @07:49AM (#17253000) Homepage
    The reason I've pretty much given up on trying to get people to use linux is its lack of a very fundamental feature : being able to download a software as a single file, and double-click this file to install the software. Depending on the distro this is either impossible or theoretically possible but always failing. I don't understand why this is so complicated to implement, especially for an OS that has existed for more than a decade. Even a certain crappy OS that I won't name handles this just fine...
  • by FireFury03 ( 653718 ) <slashdot@nexusu[ ]rg ['k.o' in gap]> on Friday December 15, 2006 @08:04AM (#17253082) Homepage
    Especially when people try to pitch it against apt-get.

    My experience of apt-get has been that it has pretty terrible ways of dealing with broken dependencies in the RPM database. When I tried it on a database with broken deps it decided to automatically "fix" the database by removing any packages that had any broken ancestoral dependencies. The result was that it automatically uninstalled the entire distribution - I've never touched it again since this experience. Whilest I have had problems with yum, it's never tried to do anything quite so crazy.
  • by doti ( 966971 ) on Friday December 15, 2006 @08:08AM (#17253100) Homepage
    I call it heaven.
    That was no joke. I went from Debian (tried Redhat too) to Slackware because I couldn't stand for dependency hell anymore.

    Of course it has a different public. I would recommend Ubuntu for a newbie, but if you have enough experience, Slack's simplicity, elegance, and control are unbeatable.
  • I have a suggestion (Score:4, Interesting)

    by ajs318 ( 655362 ) <`sd_resp2' `at' `earthshod.co.uk'> on Friday December 15, 2006 @08:27AM (#17253228)
    Whatever you do with your new package format, please ditch -devel packages. Back in the day, there was a good reason to minimise package sizes; people were using dial-up connections, therefore charged by the byte, and had slow CPUs and limited storage. So packages were pre-compiled (i.e. the distro maintainer does ./configure --with-this=ourformofthis --without-stuffwedontneed and make) to save you the CPU cycles; and the files you would not need just to use a package, only if you were trying to build something else to go with it, were separated out into a "developers'" package.

    Nowadays we have broadband, CPU cycles to spare and plenty of GB of storage. Despite the size of the repositories, there will always be a need to build and install the odd third-party package. For someone who knows what they're doing, it's as annoying as hell to be told on the package homepage I need to have libfoo installed; then have the configure script conk out because libfoo-devel isn't installed. For a n00b, it's much worse, and can be a dealbreaker.

    Separating out the -devel stuff was the right idea a few years ago; but today it is doing more harm than good. Please, let's have all the -devel files in with the main package. A user who really wants to keep everything trimmed down as lean as possible can always delete the files they don't need afterward.
  • by Anonymous Coward on Friday December 15, 2006 @08:28AM (#17253234)
    That actually leads to a very interesting idea, and one I personally haven't seen in the inevitable suggestion for a universal package system: package meta-data that could be interpreted by different distros in different ways.

    It would of course mean that each distro would have to support the same set of meta-data and tools for interpreting such data accurately and sensically, as well as having the information needed to integrate it into it's own naitive package format system... but still, I like it a whole lot better than most "universal" automagic package solutions.

    Of course, the other thing about distro specific packages is they're often compiled with slightly different features from one to the next, and even source patches at times, which might have to be taken into account for dependancies.
  • by ThePhilips ( 752041 ) on Friday December 15, 2006 @08:35AM (#17253282) Homepage Journal
    My experience of apt-get has been that it has pretty terrible ways of dealing with broken dependencies in the RPM database.

    I heard of such problem (though never used the apt-rpm by myself).

    Most often the problem was attributed to RH/SUSE love to heavily patched software which leads to requirement to have rpm depend on precise version of the patched software (glibc, perl, python, kernel headers, etc).

    Debian's packages normally try to be lax about dependencies: they do not depend on some particular version of other packages, but rather range of versions. e.g. some packaged doesn't depend on "glibc-2.3.99-cvs20041212", but rather on "glibc-2.4 and higher". (I still shiver recalling hell of manually upgrading RH/SUSE servers - after new release of glibc.)

    IMHO, your problem is ideological incompatibility of apt and of rpms as provided by vendors.

    On Debian with all Debian's repositories + several second party repositories, apt/aptitude does great job of finding compatible combination of packages to install: often it may resort even to downgrading some packages to satisfy dependencies and allow you to install request package.

  • by totally bogus dude ( 1040246 ) on Friday December 15, 2006 @08:48AM (#17253362)

    That bug thread is hilarious. It sounds like Jeff Johnson's departure is the best thing that could possibly happen to any project.

    Comment #22 From Jeff Johnson on 2004-06-25 08:13 EST [reply]
    Yes, %_netsharedpath is the designed behavior for handling RO mount points in rpm.

    The RO mount is the source of the problem. Configure rpm and use appropriately with RO /usr is the answer.

    Other problems, like "corrupted" rpmdb, are derivative on the correct use and configuration. Screaming about the symptom when the cure for the cause has been described is, well, pointless.

    Now will you please leave this bug closed?

    (Posted as someone who came to Linux with RedHat 6, then gave Debian a try when I upgraded to a brand new system and needed to reinstall -- and discovered RH's braindead package "management" wasn't actually normal, and never touched the wretched thing again.)

  • by arevos ( 659374 ) on Friday December 15, 2006 @08:54AM (#17253422) Homepage

    Nowadays, almost all applications store their dependecy files in their own folders. Yes it leads to bloat, but at least I don't break App1 when I install App2 because of a version conflict in some module. Besides, who's still running Linux on a 4GB drive and installing multiple applications these days?

    There are reasons other than bloat for separating out dependencies. For instance, say a vulnerability was reported in zlib. If every application had their own implementation of zlib, then one would have to replace zlib for every application. A shared library doesn't have this problem; it can be upgraded without problems so long as it remains backward compatible. Compartmentalising functionality is common practise in the open source world.

    However, there are various file distribution systems available for Linux that include dependency files with the application. Klik [atekon.de], for instance, wraps up applications in a self-contained compressed filesystem. However, the problem with modern Linux distributions is not so much dependencies, but a lack of a common method of installing software.

  • by cloudmaster ( 10662 ) on Friday December 15, 2006 @09:07AM (#17253516) Homepage Journal
    I fail to see why your lack of understanding about how rpm works means that rpm should not be made better. The article is about making rpm better, whereas your post is about how hard it is to learn everything about Linux. While you may, in fact, have a valid point, your point doesn't mean that rpm shouldn't finally be made into a decent package manager.
  • by doti ( 966971 ) on Friday December 15, 2006 @09:23AM (#17253666) Homepage
    There is dependency problems on Gentoo too. I have been there, and saw it while trying to install X.org 7.1.

    At least in Debian/Redhat you know there's problem in the moment you try to select/install the package.
    In Gentoo, I had to wait three days compiling stuff until it showed up.
  • by mabinogi ( 74033 ) on Friday December 15, 2006 @09:28AM (#17253728) Homepage
    maybe because when RedHat started, this was the state of dpkg:

    "Debian 0.91 was released in January 1994. It had a primitive package system that allowed users to manipulate packages but that did little else (it certainly didn't have dependencies or anything like that)
    Besides, NIH isn't all bad - without it, there'd be no competition, and there's a lot to be said for having control of something as fundamental as the package management system of your distribution.
    These days it's not so much of a problem, because dpkg and RPM are both proven to be able to suit the needs of a distribution, but back then RedHat would have wanted to be certain that their package manager was going to do what they wanted, and it may well have been easier to write their own than to try to adapt dpkg.

    The decision to use existing software or build your own is always a tradeoff, it's never cut and dried, and no matter which way you go, you'll always get someone who thinks highly of their own opinion telling you that you made the wrong decision,
  • by doti ( 966971 ) on Friday December 15, 2006 @10:18AM (#17254404) Homepage
    I would suggest you to use checkinstall [asic-linux.com.mx].
    It's a wrapper for "make install" that creates a package and installs it, so that the software:
    1) Gets cataloged on your system's package manager, and
    2) Can be easily removed with the normal system package tools.

    I made a nice script that guess all the fields of package information, like name and version (from the dir name, or from date, in case of cvs/svn/git), and pass them to checkinstall for a non-interactive one-shot install. If anyone is interested, just ask and I'll post it here.
    I works very well on Slackware, and now I'm adapting it to Debian too. (I also switched from Slackware to Ubuntu, but because of hardware support. It's not that easy to configure the kernel and required software these bluetooth/dvd-burner/usb/cellphone/digicam days.)
  • by Sentry21 ( 8183 ) on Friday December 15, 2006 @10:26AM (#17254532) Journal
    The problem with that theory is that it doesn't make any sense. Even in the Debian world, I'll come across .deb packages that need manhandling (instalation, removal, retrieval), and the debian command-line utilities (e.g. dpkg) are always simple to use when I need to. 'dpkg -i' to install, 'dpkg -r' to remove, 'dpkg -l' to list matching packages, and 'dpkg -S' to find out what owns a file.

    If you look at the output from 'dpkg --help' and compare it to RPM's, RPM provies a much longer list of options, the vast majority of which no one ever uses, burying the commonly-used functionality in a sea of terse explanation.

    The RPM tool needs to be replaced - possibly with another version of the tool, but removing all the extra cruft from the way it's used. It makes no sense to say 'Well, of course it's messy because you shouldn't be using it'. If the tool exists, it should be usable.

    Even with the APT frontend picking up the slack, Debian has managed to keep dpkg easily usable and keep the help options straightforward, to the point where I rarely have to dig for what I need to do. When I go to work and have to work with the package management tools on Fedora (yum on our workstations) or RHEL (RPM on our servers), I hear nothing but complaints about usability, speed, and reliability from coworkers.

    RPM needs an overhaul, badly, but I doubt it'll get the one it needs.
  • by Anonymous Coward on Friday December 15, 2006 @01:52PM (#17258236)
    > RPM will choke on installing a Fedora RPM on a SuSE distro

    RPM could improve on compatibility errors from using a foreign distro's RPM:
    EG: Error: "Incompatible binary format of this RPM. Unable to read this RPM.".
    OR: Error: "You are attempting to run an RPM for SuSe on Fedora...."
    Or: Give reasons why this foreign RPM is incompatible on this version of Fedora.

    One of the features of dependency checking I'd like to see is:
    RPM knows this distro was installed with CD, and prompts for the given CD, as appropriate.
    Drawback: Updated versions of dependencies will be ignored.
    Sequitor: YUM already does this thru the use of it's repositories.

    RPM should have a way to call YUM from the command-line for dependency issues.
    This would give RPM a seemless interface to YUM to resolve all dependencies for a given RPM.
    EG: rpm -i -y[i,r] something-1.1.1.rpm
            The 'y' invokes YUM and either (r)eports the dependencies or (i)nstalls the dependencies.

    Perhaps RPM should scrap YUM for dependency resolution in lew of APT.
    This would give RPM and DPKG a common "dependency resolution" wrapper, that fits closer to an LSB-centric approach.
    EG: Why have two wrappers for RPM and DPKG, rather than one?

    In either case of which dependency wrapper RPM uses, a command line interface switch for RPM should be available to call or query that dependency resolution wrapper. This would help in the confusion folks have demonstrated in their responses (above), regarding package managers like RPM and DPKG and dependency resolution wrappers like YUM and APT.
    This would also demonstrate how RPM relates to that wrapper (Yes, I know the YUM actually uses RPM, but it would be cool, if I could call YUM from RPM cmd).
  • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Friday December 15, 2006 @05:15PM (#17261376) Journal
    You are misunderstanding just a bit. The package manager isn't the problem, it's the distro. Specifically, dependencies.

    Consider: RPM doesn't depend on packages, it depends on files. That is, an RPM file will depend on /usr/bin/mozilla, not "web browser package".

    Most other systems work more sanely -- a package that needs a web browser can depend on "web browser" or even "Netscape-compatible browser", and those, in turn, could have lists of alternate packages that could fill that role. But even here, you have problems: Suppose a package depends on Firefox. Do we install the Ubuntu Firefox, the Debian Firefox, the RedHat Firefox, or the Gentoo Firefox? All of them could be slightly different, and have slightly different dependencies.

    I know you're saying "they should be the same" -- but consider Apache. On OS X, it'd be handled by launchd. On most systems, it'd be an init script -- /etc/init.d/apache -- but it might have different ways of running it, like "reload" vs "restart". On newer Ubuntu systems, it may be managed more directly by upstart. On a system by DJB, it might be handled by svscan. On Windows, it'd be a service.

    So, after we upgrade Apache, we want to automatically restart it. How does our universal package manager know what to do? Each package will know what to do -- on the distro it was designed for.

    And that's assuming coherent packages. For instance, on Gentoo, support for various things is controlled via USE flags -- for instance, mod_ssl might be part of the Apache package, assuming you have the "crypt" USE flag enabled. On Ubuntu, it'd probably be a separate package that depends on Apache. And you see this kind of thing all the time -- how do we split things into packages? What if I have a package that depends on xmms-plugins, but that's included in xmms?

    Now, if what you're talking about is a way to install packages from another system, we can sort of do that. Gentoo does it a lot -- it'll download an RPM or a DEB, unpack it into its files, and do some custom stuff to them. But you have to do that manually for every package -- figure out what it depends on -- which is why most other distros will just repackage it for you, unless you're going to end up doing it yourself manually.

    Because, you see, it's not the package type or the file format. What you're asking is roughly equivalent to asking Slashdot to combine with Wikipedia.

1 Angstrom: measure of computer anxiety = 1000 nail-bytes