Forgot your password?
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

Comments Filter:
  • 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

  • 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.)
  • Its a bit late (Score:1, Insightful)

    by Timesprout (579035) on Friday December 15, 2006 @05:10AM (#17252048)
    RPM was one of the reasons I gave up on Redhat as a distro years ago. I got sick of it choking on dependencies and ending up with half an installation. Compared to RPM APT and its front ends are a dream. Maybe Redhat should admit that RPM did not become the dominant player they envisaged because it simply was not good enough and that having so many issues with your package manager in 2006 is a very serious failing if you expect Linux to be adopted by the masses.
  • 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
  • by Psychotria (953670) on Friday December 15, 2006 @05:26AM (#17252160)
    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.
  • Re:wow (Score:2, Insightful)

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

    The decision to bring back RPM just goes to show what good work they are doing.
    You do realize that rpm is one of the most used package formats in the Linux world, right?
    They're not trying to "bring it back", but to "make it better".

    But the larger point to all this is the lack of cooperation and standards in the open source community.
    RPM is in the LSB, http://en.wikipedia.org/wiki/Linux_Standard_Base [wikipedia.org]

    Btw. I'm writing this on a FC6 box, no problems here :)
  • by cafard (666342) on Friday December 15, 2006 @06:03AM (#17252384) Journal
    I'm sorry, but exactly why is apt better than RPM? I've been hearing this argument for years and have, yet, to hear a convincing against RPM that doesn't involve elitist propaganda.

    As you don't seem to know the difference between apt and dpkg, it's no wonder that you don't have a clue as to how *dpkg* compares to rpm. You're shouting against elitist propaganda, yet you failed to even look the slightliest into the subject yourself...
  • by Antique Geekmeister (740220) on Friday December 15, 2006 @06:18AM (#17252462)
    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 think this is easy to solve are the people who are happy to update 15 packages to fix one program that has a dependency it doesn't even really need on an upgraded version of another, trivial package, and then are surprised when they destabilize their whole OS because the other 1500 packages have never been tested with those new 15.
  • by Anonymous Coward on Friday December 15, 2006 @06:35AM (#17252566)
    How can anyone trust RPM with his system when the main developer finds it is perfectly ok [redhat.com] to leave the RPM database in an inconsistent state if an error occurs? I thought it was a joke when I first read this bug report, but apparently it is not.
  • by cyclomedia (882859) on Friday December 15, 2006 @06:56AM (#17252682) Homepage Journal
    ... 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:Good. (Score:4, Insightful)

    by Tet (2721) <[slashdot] [at] [astradyne.co.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?

  • by gilboad (986599) on Friday December 15, 2006 @01:26PM (#17257852)
    I've been reading /. for years now, but seldom did I see so many clueless posts and half-baked flame-baits packed in a single page.

    Just for the record. (For all the clue-less posters out there.)

    A. RPM is package structure.
    B. RPM is a package manager.
    C. RPM does not, and let me repeat myself, does not -resolve- dependencies.
    D. RPM uses external tools to resolving dependencies; Namely yum, or, wait for it.... apt. (Though AFAIR apt-rpm does not handle bi-arch making it less usable for x86_64/PPC64)
    E. So called dependency hell only happens when you:
    - Combine different software repositories.
    - Someone at RedHat/Fedora/Debian releases an incompatible update. (Happens more on Fedora; less on Debian/RHEL)
    - You're using an unstable branch.
    F. The introduction of Fedora (and now RHEL) extras project goes a long way to set a higher, Debian like packaging standards. (And again, this has -nothing- to do with RPM itself)

    Yes, Debian has -less- dependency problems (as long as you stick to the stable tree), but this has -nothing- to do with RPM, or even yum for that matter.
    At least get the facts strait before you start FUD /. to death.

    BTW, I spent half of last night manually recovering (using dpkg) a dead Debian Sid workstation that somehow botched the 2.6.18 upgrade (dist-upgrade)... and trust me, neither apt nor aptitude/dselect managed to solve the blunder - and somehow, you won't find me shouting like a baby that "Apt-get (or dpkg) should be rewritten from scratch).

    - Gilboa

It's time to boot, do your boot ROMs know where your disk controllers are?

Working...