rum

software-managementOn e of the things Novell bought when they purchased Ximian was Red Carpet. Red Carpet is/was a centralized (software) management tool for system management across a network. One of base tools was the software management program rug. It has been used as a development base for the new zen software management system in Opensuse 10.1 and beyond.

The features of rug are quite impressive: besides the usual stuff it was for example able to install and remove packages at the same time. It also supports channel acronyms, downgrades, and so on.
Now some people who previously used yum but missed some of the features and behaviour from rug now created some kind of frontend for yum which comes along with all these rug-features. The name is rum.

The list of features is pretty impressive, and there are packages for FC4 and FC5 as well as for the Suse variants.

Although I haven’t tested it yet I really appreciate the fact that more and more software management tools are using the yum way, or at least the XML package metadata format which is used by yum to manage the software.
Now the only thing missing is a way to enter the debian world. My dream is one common repository format which can be read by all distributions. We could then fill such repositories with LSB rmps, and gone would be all problems of different package formats for different distributions🙂

However, I’m curious how the new rum will develop and if it will find it’s way into the Fedora Core or Suse world.

4 thoughts on “rum”

  1. We could then fill such repositories with LSB rmps, and gone would be all problems of different package formats for different distributions.

    I’ve got a better idea, we could use debs everywhere. I mean seriously why are RPM’s any better (I admit the last time I used RPM’s was five years ago and it was shockingly bad, the only reason I’m still with linux is apt-get and apparently Yum is no better than it ever was according to a colleague). Oh well this may start a flame war but surely the time is right for a new package management system altogether like GoboLinux’s fresh approach or even zero-install.

  2. (Beware, you got me in a pretty bad mood, so be prepared that this answer focuses on the facts, not on being friendly.)

    Get your facts right: the things you can compare are the packages rpms and debs. Or the program rpm, and the program dpkg. Or the software management apt and yum, or for example urpmi, yast, smart, rum, etc. Since you are mixing apt and rpm in some way it looks pretty much like you do not make this differentiation. And that is terrible wrong.

    So, no, this will not become a flame war, because you compare apples with fruit boxes – that doesn’t make sense, so I can’t discuss or flame it.

    If you want to discuss the topic if debs would be better than rpm, well, list your reasons, I would love to see such a comparison. But do it right, and do not talk about apt in this case, because it has nothing to do with the comparison. If you think otherwise, well, read a bit about that topic.

    And, about a comparison of yum vs apt: if you colleague claims it is no better, then I claim it is better. And now?
    Write about facts, in other cases I cannot take this discussion serious. And, yes, I have some facts why I claim that yum is superior to apt in quite some situations. Just read this article about exactly that topic. The text is a bit old though, apt and yum both have strongly developed in these days. But the basics are still true.

    And, last but not least: If you would have enough knowledge about the whole topic, you would realize that my solution which I proposed is independent from the used software management system. I talk about LSB rpm and XML package metadata. I even now a apt version which is already able to deal with both these things perfectly well.

    As a summarize: I do not talk about replacing debs in the debian world, I talk about using more LSB rpms which are a standard which can be understood by all major distributions – yes, debian can handle LSB rpms perfectly well. The problem which I point out is a common repository format to store these packages, nothing more. Your idea completely failed this point, introduced an unrealistic idea (replace already existing standards), mixed apples with fruit boxes and did not provide any fact except something you heard from a colleague who did not even tell you about the yum plugin system, I guess.

    Tell me, how serious should I take such comments?

  3. I did make a mis-giving towards my understanding of the difference between a package manager and a package. I do know the difference and have produced debs and can understand the need to unify the types of packages. My real question is ignoring the package management software (hell all I want is to click install and think no more about it). Why is a RPM be it LSB compliant any more suitable than a Deb? (other than the fact that it is a standard? which is debateable given that it would have to be both by concensus a standard and by quantity of usage rather than just appointed so, although I do recognise LSB’s authority)

    The problem which I point out is a common repository format to store these packages, nothing more.

    Then why didn’t you say that instead of: We could then fill such repositories with LSB rmps, and gone would be all problems of different package formats for different distributions?

    Tell me, how serious should I take such comments?

    Less so

  4. Ok, so I misunderstood you, sorry for that.

    So, about deb vs. rpm: unfortunately I never saw a good comparison of both formats. I know how to basically package rpms, and that’s it. If you have a good comparison or some reasons to discuss, write them down, I really would like to discuss them. Unfortunately, such comparisons are hard to find. I tried several times, but normally you come to a page where someone compares apt to rpm or even worse.
    The only thing I found was this comparison which seems to be a bit outdated (2003) in some cases. Looking at that comparison it comes out equal somehow because they have both advantages and shortcomings.

    So long my point is: we have two package formats (actually more if you include all other attempts which are less spread, like autopackage, rpath, Slackware’s solution, Gentoo’s solution, etc.; but let’s focus), one was set as standard, every distribution can use these standard packages now, so let’s take them. I want it work.
    And if it turns out deb’s are superior, then let’s take these if it is realistic that the LSB accepts them as well. The principles are the same (provide somehow binary data with dependencies), so what do I care how it’s called?

    “The problem which I point out is a common repository format to store these packages, nothing more.”
    Then why didn’t you say that instead of: We could then fill such repositories with LSB rmps, and gone would be all problems of different package formats for different distributions?

    Well, actually I said that in the sentence before: “My dream is one common repository format which can be read by all distributions.” And I prefer LSB packages to fill because that is the smallest common denominator which is realistic at the moment. Everything else is like autopackage: a cool idea which no larger group uses in reality.

    One word about me: please keep in mind that I am a Fedora Core packager, I maintain two packages and therefore I can hardly be unbiased. Additionally I never made a deb package (but I used debian for quite a while).

Comments are closed.