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 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?

  • 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.
  • by simm1701 ( 835424 ) on Friday December 15, 2006 @06:03AM (#17252382)
    apt and rpm don't compete - they are not even similar in purpose - each fill a different role and are cooperative ratehr than competative.

    In fact apt can work quite well with rpms (the apt for rpm project springs to mind)

    Maybe you are confusing the issue with .deb files and dpkg?

    Personally I find .debs a slightly better package structure/file structure than rpms, and dpkg a more flexible and easier to use (getting both is quite an achievement I think) command line.

    However those are personal preference and while not quite as contentious as emacs vs vi I'm sure they won't be solved any time soon.

    You are right to bring up apt though - its apt that makes distros like ubuntu and debian shine. Or more importabltly its the repository organisation and discipline that sits behind apt. Without this organisation server side, the package files clearly listing each package which dependancies and conflicts, then the system is all but meaningless, and thats where apt for rpm has fallen down (not that it doesn't work, I've used it with several rpm respositories, its not bad but several times I've had to hand resolve large messy conflicts, I've had to do that on debian true, but only when doing really messy mixtures of sid sarge and woody all on one box during times of serious upheaval - gnome 1.4 to gnome 2 springs to mind)

    Getting rpm and apt to run better together is not really about code changes or design changes to either apt or rpm (or the existing apt for rpm software). Its about making good rpm respositories and the package files that go with them - that would be a huge improvement for starters.

    The main fustration people feel with rpm is dependancy resolving, being able to type rpm -i gcc-4.1.rpm and having it just work would be nice. People don't associate the same problem with the .deb system as they very rarely run somehting like dpkg -i gcc-4.1.deb - usually they will type apt-get install build-essentials or apt-get install gcc and it will "just work" (or they will use dselect but thats another topic)

    I think that is what really colours peoples perceptions. They feel pain frequently when they use rpm (I know I do). They don't feel pain when using .deb files via apt (and lets face it - if you are sing a distro with .deb you are almost certainly using apt or dselect). This perception causes the view that rpm is crap and .deb/dpkg is far superior. The real problem is though not the package management tool at all. Its the repository management policy, something that debian and debian based projects has had right for a long time.

  • by davidkv ( 302725 ) on Friday December 15, 2006 @06:08AM (#17252412)
    Did you try the most obvious way?

    # yum install anjuta

    Since Anjuta is in the Fedora Extras repository you might have to enable that first (i.e. add "--enablerepo=extras" to the previous yum command line)
    Actually, I just tried it. It worked fine:

    # yum install anjuta
    -removed a lot of yum output-
    Installed: anjuta.x86_64 1:2.0.2-11.fc6
    Dependency Installed: anjuta-gdl.x86_64 0:0.6.1-5.fc6 autogen.x86_64 0:5.8.7-3.fc6 gnome-build.x86_64 0:0.1.3-11.fc6 graphviz.x86_64 0:2.8-5.fc6
  • by Jaruzel ( 804522 ) on Friday December 15, 2006 @06:12AM (#17252426) Homepage Journal
    I am not a Linux user, but I am a software developer, and it seems to me, that ALL the distros could benefit from a universal package manager, that was compatible with all the major package types?

    Or do I completely mis-understand how things work under linux ?

  • by ThePhilips ( 752041 ) on Friday December 15, 2006 @06:17AM (#17252452) Homepage Journal

    Worth to mention that apt now deprecated in favor of aptitude. Aptitude marks packages installed as part of dependency resolution and when you later remove the installed software, it would also remove all automatically installed packages.

    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.

    +100. yum is dumbest and slowest tool I have ever seen. Especially when people try to pitch it against apt-get. And aptitude is ages ahead of any package management RedHat ever implemented.

  • Re:wow (Score:3, Informative)

    by Antique Geekmeister ( 740220 ) on Friday December 15, 2006 @06:49AM (#17252660)
    Yum was slow for solid technical reasons: the repository information was inefficient, there weren't enough fast RPM mirrors, and the db4 database behind RPM was painful.

    Fortunately, db4 seems to be dead: it's been replaced in such lightweight applications by SQLite, there are a lot more and faster mirrors available, and the repository information is stored more effiently, or at least handles a lot faster with faster modern machines. So it's overall gotten a lot better: take a look at the versions of the past year or two to see how good it's gotten.
  • by wolf08 ( 1008623 ) on Friday December 15, 2006 @08:38AM (#17253300)
    You can create aliases to commands to make them as short as one letter commands. From a howto I saved a while ago:
    First of all open a terminal and edit .bashrc
    near the end of the file uncomment so it looks like this:

    # Define your own aliases here ...
    if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
    save and close the file. Now you can define your own aliases in a file named ".bash_aliases" (note the dot before the name please) in your home directory. Some samples:

    alias df="df -h"
    alias h=history
    alias untgz="tar -xvfz"
    alias untbz2="tar -xvfj"
  • Re:Good. (Score:4, Informative)

    by ajs318 ( 655362 ) <`sd_resp2' `at' `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.
  • Dumb Asses (Score:1, Informative)

    by Anonymous Coward on Friday December 15, 2006 @09:02AM (#17253494)
    RPM is not there so you wannabe sysadmins can play with this or that. It's there to maintain _production_ systems. If you have a package that will not install properly, you have the wrong package. If it's not specifically for your system stay away. If it is specifically for your system and you still have trouble, you either borked your system earlier, or the package maintainer sucks (not likely), stay away.

    Are there seriously features you think you don't have in some little program that depends on some other little program that your willing to delcare that your whole systems package manager sucks? Too bad, quit whining, stop playing with packages you dont understand. You'd be fired fucking with systems like that.

    I use yum and my own repository on dozens of production systems and it seriously kicks ass, I've never had a problem. I've seen it update 200+ packages in one pass and not fuck anything up. Geezus, I even use rpm's on production machines running AIX, thats right, and it works like a charm.

    This is fucking great news.
  • 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).
  • by liliafan ( 454080 ) * on Friday December 15, 2006 @09:47AM (#17253944) Homepage
    Sorry but I have to step in on this, with gentoo if there is a dependency problem it will notify you as soon as you attempt to emerge a package. In most cases there is no problems with dependencies that portage cannot resolve itself, however, if you unmask a package you may end up having to unmask a bunch of other packages as well.

    Yes it is possible for an emerge to break after you have been compiling for a huge amount of time, but this has nothing to do with a dependency, it has to do with either a the codebase on the application you are using being broken or the ebuild itself being broken.

    This being said I personally use gentoo because I actually like having that much control over my system, I recently installed Suse 10.1 on my wifes computer and was seriously disappointed since the package updater was broken (I used suse from version 6.0 - 9.0) and I used to have a nightmare with dependencies almost everytime I installed a package. I used fedora at a company I used to work at and got to the point where I would dread having to install anything because of the dependency problems. I used debian and I was fairly impressed, however, I got fed up with having to use out of date packages. I have recently install Ubuntu on my wifes computer and overall I have been very impressed with it, so far I haven't had any dependency problems whatsoever.

    Taking a step back, I am not attempting to knock anyone elses preferences, I am just expressing my experience with the various package managers, so far the most impressive for me have been portage on gentoo and apt/dpkg on ubuntu.
  • by Anonymous Coward on Friday December 15, 2006 @11:00AM (#17255098)
    Sure, _everybody_ in Argentina has broadband.
  • by tjwhaynes ( 114792 ) on Friday December 15, 2006 @11:02AM (#17255124)

    With modern packaging systems, there's occasionally a dependency that is just automatically marked and installed, but mostly it just becomes impossible to install something -- and I fear to install from source as in option 2 above, for I may break the packaging system. A package depends on packages X, Y, and Z, each of which have ten dependencies, and most of which conflict with others, or are reported as "won't be installed" but no reason is given. If I find a way to force it, it doesn't work, or it breaks other packages, or most likely it breaks the packaging system.

    If you are running a distro (say Fedora Core 6) against potentially inconsistent repositories (say ATRPMs), then you need a package manager that is smarter than APT or YUM. I've used Smart Package Manager [labix.org] to solve these complex problems for a while. It's not perfect - it may hang if you attempt to upgrade an entire release using it - but it is capable of downgrading parts of your system to match up unusual RPMs. Of course, if you stick "odd" RPMs into your system, you will have to remove them before attempting to upgrading to, say, Fedora Core 7 if you wish to retain your sanity. Package dependencies are a simple mechanism to tell you what a particular package needs. Working out all the kinks requires some pretty good graph code.

    I've run RPM-based and DEB-based systems for many years. I've never hesitated to install from source if there is no RPM available for a particular package. You only break your packaging system if you overwrite the libraries under RPM/DEB control with newer ones. Almost all source packages install into /usr/local by default and will not (normally) conflict with anything you have installed from your distro. If you wish to be really paranoid or you know that there will be problems, you can always install into an entirely separate directory tree (such as /opt).I do this for 2.3.x development versions of the GIMP, for example, where the development libraries *might* conflict with the installed GIMP 2.2 ones.

    Of course, you can be smarter too - you can go the next step and actually build packages for your system. Many packages have .spec files around. Similar instructions are available for DEB packages too. checkinstall can be used to tag files from a source install, making it easier to pull the files out too.

    Toby Haynes

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

    by Anonymous Coward on Friday December 15, 2006 @01:07PM (#17257466)
    RPM supports both file dependencies and package dependencies, you don't have to "emulate" a package dependency, you just have to Requires: otherpackage, and in fact that's the most common method for hand-written dependencies. What's more common than actual file dependencies (with a full path) are autogenerated dependencies: libraries automatically provide liblibname.so.n (without a path), and all programs requiring the library automatically require liblibname.so.n. (Why should you have to list the library packages manually? That's what ldd is for!)

    As for virtual packages, they're perfectly possible with RPM too, that's what Provides is for. For example, firefox, dillo, elinks, lynx and wget provide the virtual "webclient" package, httpd, boa and others provide the virtual "webserver" package.
  • by metamatic ( 202216 ) on Friday December 15, 2006 @01:30PM (#17257906) Homepage Journal
    Hell no. The last thing we want to do is encourage Linux users to start running random scripts they downloaded from web sites, just because they have .package in the name.

The absent ones are always at fault.