Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software Businesses Software Linux

Fedora Project to Help Revitalize RPM 334

Posted by CowboyNeal from the breathing-life-back-in dept.
-=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 More

Fedora Project to Help Revitalize RPM

Comments Filter:

  • First improve the UI (Score:4, Insightful)

    by MichaelSmith ( 789609 ) on Friday December 15, 2006 @04:53AM (#17251966) Homepage Journal

    RPM has about 30 options you can enter from the command line and if you don't get the command right it just echoes the list back at you, as if that is any help. Most shell commands try to help by providing a few simple examples.

    Package managers, like revision control systems have complex functions and their help systems need to do more than just say here are the options you can use

    • You Have It All Wrong (Score:5, Insightful)

      by eklitzke ( 873155 ) on Friday December 15, 2006 @05:10AM (#17252044) Homepage
      I have read through the (very few so far) messages in the new mailing list, and based on the discussion there as well as the similar discussions that have taken place in the past, I think that the general consensus is that users should not be using the rpm command line tool for package management. Rpm (the CLI tool, not the format) should be like dpkg in the Debian world -- a very low level tool for package management. If you want something user friendly to use at the command line, use yum, apt-rpm, yast, or whatever other high level tool floats your boat.

      In fact, to a large degree it is more important that better rpm bindings (especially for python) be written. This is how yum works -- it is able to do all of this using the python bindings, instead of calling the rpm tool itself. Calling rpm -i foo.rpm should really be a last resort option. (For those that are curious, yum already has a --localinstall option for doing this.)
      • users should not be using the rpm command line tool for package management.

        Repository management works well in pkgsrc with pkg_add, pkg_del, pkg_info, etc. There is no need to add an apt or yum lookalike over the top, and the interface is simple and intuitive.

        The situation with yum seems to be that rpm is in the THB (too hard basket) and they are writing a wrapper to hide the problem.

        • Re:You Have It All Wrong (Score:4, Informative)

          by davidkv ( 302725 ) on Friday December 15, 2006 @05:32AM (#17252206)

          The situation with yum seems to be that rpm is in the THB (too hard basket) and they are writing a wrapper to hide the problem.
          rpm has no concept of repositories. It's main task is to install/remove/query/verify/etc rpm packages.
          Yum and others handles repositories and dependency solving.
      • ... it shouldnt BE at the command line.

        "installing packages" and "resolving dependencies" should be done by turbo nutter linux admins(though i'd like to be one myself one day). "Installing a program" is what non-geeks do, and they need a happy shiney add/remove programs applet. Oh and one that explains what all the apps with 4 letter acronyms prefixed in k or x actually DO would be handy too. Even installing GCC and an IDE should be possible with a couple of clicks of the mouse.

      • Re: (Score:2)

        by jimicus ( 737525 )
        Rpm (the CLI tool, not the format) should be like dpkg in the Debian world -- a very low level tool for package management. If you want something user friendly to use at the command line, use yum, apt-rpm, yast, or whatever other high level tool floats your boat.

        It wasn't all that long ago that this wasn't possible in RedHat. IIRC, everything before Fedora Core, "rpm -ivh <package>" was exactly what you did. If it had dependencies, it would tell you, but actually solving them was your problem. This

      • Re:You Have It All Wrong (Score:5, Interesting)

        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.

  • I have a... (Score:5, Funny)

    by A beautiful mind ( 821714 ) on Friday December 15, 2006 @04:54AM (#17251968)
    ...good solution for them. Or should I call it apt?
    • Sorry people. I thought the humour impaired get out of the woodwork at a much later date. I'll go away in shame. Yeah, I did not know that .deb is the packaging format, after all I only use debian on my desktop for more than half of a decade...

    • Re:I have a... (Score:4, Funny)

      by pembo13 ( 770295 ) on Friday December 15, 2006 @05:05AM (#17252020) Homepage
      You shouldn't since apt is in no way involved.

    • Re:I have a... (Score:4, Funny)

      by Jesus_666 ( 702802 ) on Friday December 15, 2006 @05:28AM (#17252178)
      I am forever indebted to you for your apt remark. I am sure that a common standard will emerge, which we can all use to install Free Pacman clones and video game ports with a single klik. After all a smart package manager is a recipe for success.


      ...I shouldn't post when tired. I tend to emulate Mookie, badly.

      • Re: (Score:2)

        by geschild ( 43455 )

        I am forever indebted to you for your apt remark. I am sure that a common standard will emerge, which we can all use to install Free Pacman clones and video game ports with a single klik. After all a smart package manager is a recipe for success.
        yummie! :P
      • You own me a keyboard for the damage the mineral water out of my nose did to it... :)

    • Re: (Score:2)

      by daBass ( 56811 )
      apt and rpm are different things. apt is a package manager for - mostly - the .deb package format.

      rpm is both the file format and *a* tool to work with them, just like you can use apt to install a single, downloaded .deb. But in the Fedora world, "yum" compares to apt as a package manager and performs pretty much the same role and does it pretty much as well as apt does.

      Another major RPM distro is Suse. In their world, YAST compares to apt.

  • Code cleanup... (Score:5, Funny)

    by nighty5 ( 615965 ) on Friday December 15, 2006 @04:58AM (#17251984)
    Job #1 is to take the current RPM codebase and clean it up.......

    Easy job, this took care of it.... :

    rm -rf /var/lib/rpm

  • Has RPM improved at all? (Score:4, Interesting)

    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.

    • Re: (Score:3, Insightful)

      by Antique Geekmeister ( 740220 )
      Every dependency system has that, including RPM, pkg, apt, and even Perl's CPAN setup. Resolving dependencies like that is not something bare RPM can do on its own: it needs some sort of knowledge of the various places you might pull software from and resolve the discrepancies, like Yum attempts to do, on top of RPM. Different programs all use common utilities, like modutils and tar and glibc and OpenSSL and popular Perl libraries: updating one of them may mean needing to update the others.

      The people who t
    • Do RPMs still have a confusing dependancy circle hell?
      No. It's more akin to a mobius strip.

  • misread (Score:4, Funny)

    by lovebyte ( 81275 ) * <lovebyte2000@gmail3.1415926.com minus pi> on Friday December 15, 2006 @05:01AM (#17251998) Homepage
    For some reason, I had misread "...a thorny issue ever since Jeff Johnson, the original maintainer of RPM, left Red Hat." as Horny issue. So I did a google image search [google.com] on Jeff Johnson, and I can confirm it was horny (in a homo-erotic way).

  • Anti-FUD Post (Score:5, Insightful)

    by pembo13 ( 770295 ) on Friday December 15, 2006 @05:11AM (#17252062) Homepage
    1) RPM is not equivalent to APT , or Smart
    2) RPM is not responsible for _solving_ deps
    3) RPM is both a file format and a program to use the format
    4) RPM is _not_ a package manager
    5) RPM has little to do with how much you may love your Debian distro of choice (unless you made that choice solely on the file format of the packages used by your distro)
    6) The existence and use of RPM does not work against your distro of choice, and so there is no reason to fear/hate it

    • Come again on that one? (Score:5, Informative)

      by MichaelSmith ( 789609 ) on Friday December 15, 2006 @05:23AM (#17252134) Homepage Journal
      4) RPM is _not_ a package manager

      That would be the Redhat Package Manager, right?

    • While I do not disagree with you, there's still an important question, namely: "Why do we need RPM for?" and once you answer that, there's a tougher one: "Does RPM have the potential to do it better than the existing solution(s)?". If not, then it should die - people responsible for packaging apps will have one less format to take care of.

      • Re: (Score:2)

        by pembo13 ( 770295 )
        I honestly don't care what file format the packages come in. So I have no answer as to "Why do we need RPM for?" but I would also ask "Why do we need DEB for?"

      • *Package-format* to take care of ? (Score:5, Informative)

        by DrYak ( 748999 ) on Friday December 15, 2006 @09:23AM (#17253670) Homepage
        If not, then it should die - people responsible for packaging apps will have one less format to take care of.


        No, it's app packager that still think in term of "packaging format" that should die.

        What are you thinking ? That because a packager did pack a "RPM" then it surely going to work on any RPM-based distro ?
        You're plain wrong. If it happens to work that way in the DEB-world (one single DEB good for most cases) it has nothing to do with DEB being a supperior format or whatever. It's just that DEB happens to be the native format for Debian and most DEB-using distros happen to be debian customized variants with a different name.

        Packages are only a practical way of storing together the files, the special install scripts and the dependencies needed to install an application. Anyone is mostly as good as any other of them (and thanks to some facility like "alien", may be substituted freely), with maybe the exception of Slackware's tgz (less informations in there).

        What package manager have to think about isn't the package format in itself. They have to think about the distribution which they are targeting. Each distribution out there, even if it uses a common packager, is a different mix of libraries and application versions.

        A rpm designed for Red Hat *may* work on some RH-derivated clone, but it may *not* on opensuse because this is a different distribution (which in fact started it's life as a Slackware derivative and added aspects of RH over time [wikipedia.org]).

        If RPM get deprecated and replaced by DEB in most distros that currently use it, this won't make the packager's task less difficult. They'll be only using DEBs, but they'll still have to build a different DEB for each different distribution familiy.
        Most problems that people are complaining about will still be here : YaST will still be as slow as usual, some badly behaved package managing systems will still break often, and users who didn't download the correct package will still encounter dependency hell.
        In fact, more confusion is likely to happen among inexperienced users : "But I did download the DEB, my system is DEB-based, why doesn't it work ? - Yeah but did you download the Debian-specific or the RH-specific DEB ? - What do you men ? It's all DEBs it's all the same stuff... - (Sigh)"

        The best way to avoid dependency problems isn't switching the package format, but either :
        - using static and/or libraries included binary packages (like OpenOffice) and you're sure everything is included in the package. But then you loose all advantages of system-wide updates or upgrades (*).
        - using a package reporitory that contains RPM specifically designed for YOUR distribution (get rpms for your openSUSE from Packman [slashdot.org] instead of some random site). Which is the method I recommand the most. ...If you need a truly universal package format, source code (.tar.bz2) is the only way to go...

        ----

        (*) - What I mean is that is some library, like ffmpeg has newer ability (like better capability at handling latest Microsoft WMV format), on a system that uses system dynamic libraries (like say VLC installed from Packman on a suse Linux), you immediately take advantage of it. On a system were every application has it's own set of libraries (like OS/X or GoboLinux or a package with all libs inside), you'll have to wait until next release to take advantage of it.
        Same for security : when a security flaw was found in "libtiff", under Linux, you have only to download its patch and all your graphics applications are secure again. When WMF flaw was found on Windows (were mostly each application has its own copy of WMF routines), you had to check each application and patch it (at least microsoft designed a tool to simplify the process).

    • 4) RPM is _not_ a package manager

      What would you call it, then?

    • Re: (Score:2)

      by pembo13 ( 770295 )
      Number 4 is wrong - I was trying to communicate that it was not for resolving dependancies.

    • 4) RPM is _not_ a package manager

      Is this one of those recursive initialisms like GNU?

      RPM's Painfully Mutable
      RPM's Pretty Mindwarping
      RPM Perpetually Mangles

  • 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.
    • It's a trade-off. Debian's flat text-based database means that it essentially does a --rebuilddb, and stores the resulting database in RAM, nearly every time you invoke the package manager.
      • Uh....

        So? I mean, unless you've got crazy-small amounts of ram. It's not like it slows it down any, as far as I can tell.

      • But why then apt-get works faster than yum? Earlier versions of apt were written I think in Perl (yum is written in Python) but still yum (implemented after apt) seemed like step in wrong direction.

        Also, yum is even slower than aptitude and aptitude does one hell of checks and tests - as well as pile of algorithms to solve dependency problems. (Never living with four concurrent repositories was easier in my life.)

        That really surprised me when I found out that Debian's apt doesn't use database for its

        • Re:Good. (Score:4, Informative)

          by ajs318 ( 655362 ) <sd_resp2@@@earthshod...co...uk> on Friday December 15, 2006 @08:49AM (#17253376)
          APT has an easier time of managing dependencies than yum. That's because Debian's (well-thought-out) way of doing it was to have packages dependent upon packages, rather than specific files. And a package can provide more than one package. For instance, "www-browser" is a virtual package; there is no installable package called www-browser. But iceweasel, konqueror, links and so forth all claim to provide a package called "www-browser". Any application that needs a web browser (but doesn't care which one) only has to depend on www-browser. And so forth, and so on.

          You can roughly emulate package dependency using specific files (or symlinks) within packages which are just there to deal with dependencies, but it's messy compared to a system designed properly from the outset.

          • Re:Good. (Score:4, Insightful)

            by Tet ( 2721 ) <slashdot AT astradyne DOT co DOT uk> on Friday December 15, 2006 @10:27AM (#17254544) Homepage Journal
            APT has an easier time of managing dependencies than yum. That's because Debian's (well-thought-out) way of doing it was to have packages dependent upon packages, rather than specific files.

            Bollocks. You might claim (although I'd probably disagree) that apt under Debian has an easier time of resolving dependencies than does yum under Red Hat. But apt under Fedora vs yum under Fedora? Probably fairly equal, I'd say. I'm also slightly bemused by your implication that RPMs are dependent on files, rather than on other packages. Where on earth did you get that one from?

    • I had to do that too until I just switched to Ubuntu then I could just focus on my work. I don't even miss all the 1000+1 KDE options and all the flashy menu effects, the Gnome defaults and dpkg/apt repositories just work for me. It was sort of like growing up (or getting lazy). When I was a Linux noob I liked to play with my options, customize my KDE desktop and choose between a 100 different screen savers. I even ran Gentoo for a while there, compiled for 2 days straight! Now, I just need my work done and
      • Haha, I'm a Gentoo->Ubuntu convert.

        The first time I tried Ubuntu (OK, honestly, the first time I tried the one from 2 releases ago, 'cuz the 3rd release back sucked) it was like someone had installed Gentoo, then spent a few days configuring 99.9% of everything exactly the way that I wanted it, including all the shit that I never had the time/patience to figure out how to do on my own.

        Wonderful. Perfection. It'll take one hell of a distro (or one hell of a screwup on Ubuntu's part) to get me away from
    • Older versions of Yum and RPM didn't cleanly handle any RPM operations done at the same time as Yum: this tended to corrupt the database. That said, there are also useful updates to Yum and toe the underlying RPM and database tools you probably want to make sure are updated. And if you're still running Fedoare Core 1 or Fedora Core 2, you're getting what you deserve: do a clean update and I suspect you'll be very pleased with the improvement.

  • Fedora Project to Help Revitalize RPM (Score:5, Funny)

    by SeaFox ( 739806 ) on Friday December 15, 2006 @05:19AM (#17252112)
    So I guess they're really going to "Rev up" the RPM's?

    [dodging tomatoes]
  • this is, perhaps, offtopic, but the biggest gripe I have with Fedora is the software updater. I dunno about other people, but I'm uninterested in updates to stuff I don't have installed.
    • It's gotten better: the Fedora Core 6 version, with the various plug-ins, is very about as good as apt. Point it to your base repositories and to a good extra package repository like Livna, and it's a match for apt.
  • 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 ins
  • Why bother? dpkg/deb is maintained and does everything that rpm does. These days we all use frontends to rpm/dpkg (yum/apt) anyway, so what does it matter what the archive format is?

    Isn't this like picking between gzip and bzip? Just pick the one that suits you better. The choice in this case is between the unmaintained rpm and the maintained dpkg. If it really bothers redhat, just fork dpkg and call it rpm. As if it makes any difference at all to end users.

    What magical feature are they going to add t

    • Re: (Score:2)

      by delire ( 809063 )
      Agreed. The massive task of switching to dpkg shouldn't be underestimated, but it seems like the decision to not do this has more to do with a fear of losing identity than anything else, as though it were a 'spiritual concession' of some sort.

      Any good distro differentiates itself through offering a quality user experience. Look at the massively popular Ubuntu and the rising of Xandros. Both are Debian based distributions but favoured for different reasons. They are unique yet on an architectural level the

  • 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.
  • I've read through most of the comments in this thread (and many more over the years) comparing RPM with Debs and ports and others.
    But I still have a question that I haven't been able to get a satisfactory answer to. I may have missed it though, so bear with me while I articulate my thoughts.
    Why all the fuss about a package manger? I spend most of my time on Windows and OSX, and only occasionally (when doing some dev work) on Fedora 5. Almost all installations on OSX and Windows are self sufficient. For thos
    • Shared libraries don't just save disk space, they save RAM. If you include a complete copy of, e.g., the gnome libraries in every gnome applet that you install, you'll end up with a copy of those libraries in memory for every applet you run. Unix shared libraries are implemented that way for a reason, not just because distribution makers can't figure out how to just shove everything in a single directory because it's too hard to get dependency handling right. (Which is why MS does it the way it does--they h
    • As a primarily Linux user who occasionally must support Windows, there are things with the Windows installation method that I wish were different.

      For example, in RPM distros I like to clean up packages that I do not use. It's pretty easy because I can easily generate a query with summary information telling what every package does. In Windows this is quite difficult. The Add/Remove programs has little information and doesn't include all packages. It's difficult to determine (or at least I don't know how) wh

    • Re: (Score:3, Interesting)

      by arevos ( 659374 )

      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

  • 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...
    • 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.

      Quitter! http://klik.atekon.de/ [atekon.de]

  • I have a suggestion (Score:4, Interesting)

    by ajs318 ( 655362 ) <sd_resp2@@@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.
    • I understand what you are saying. However, I'd go one further and say that, ideally, the package ought to be able to have sub-packages inside it that are optionally installed.

      If you could have bundle packages, you could install just the application and request the devel stuff if you wanted. Better yet, if you were packaging software for sale, you could include all the dependency packages in your application package and install whatever bits were missing.

      I'd also add that the REAL reason RPM is not as conven
  • Wow, so many negative comments. I like yum and rpm. They work for me.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close