rpms and managers

So me and a friend of mine start discussing rpms and debs after I tell him that I’ve been testing openSUSE and Fedora. I’m posting it here cause you openSUSE guys will obviously have rpm experience. It goes like this:

Him:
I hate rpm! I won’t use a distro that uses it. I used Mandriva for a while before I found Ubuntu and I was always getting headaches because of the package manager.

Me:
from what I understand the package manager’s faults would be those of itself rather those of the rpm format. There are multiple managers for rpm like Zypper (for SUSE), Synaptic (PCLinuxOS), etc than just Urpmi.

Him:
it was a massive ***** to install anything that wasn’t in the repos.
Comparatively, I can throw apt a deb and it’ll install the deps for me before installing the deb. It won’t make it halfway through and then **** off telling me to “choose a pkg”. It chooses the most compatible pkg.
I have to get ***-****ed by rpm before anything can get done and even then the pkg won’t necessarily get installed.
It almost seems like rpm’s pkg resolution isn’t recursive or it just gives up really easily.
I find that as soon as rpm has a choice of pkgs to provide a req, it ****s off faster than superman on ritalin. When you finally choose a pkg, it will turn out to be incompatible with another dep of the original pkg. Then you’re really ****ed and it’ll be easier to survive a zombie invasion rather than figuring out which of the 5 choices is compatible.
Makes no difference because the problem is inherent to rpm, not the mgr.

Me:
hmm… So you had this experience with Mandriva only? Are you sure you’re not confusing Urpmi with rpm? How were you able to determine that it was the package format and not the manager that was messed up?

Also some rpms are made for different distros so they might have different nomentclature and assumptions of what’s already installed (i.e. a Fedora rpm vs a openSUSE one).

Still I think you might try to give SUSE or Fed or even P.L.O. a shot. It wouldn’t hurt to attempt to broaden your horizons a bit. This could just be Mandriva’s problem. You might even like the others even if you ultimately choose to stick with Ubuntu anyway.

It wouldn’t hurt, especially if you have a test machine.

Him:
tl;dr rpm allows reqs specified as pkgs or provides (a capability, file, etc) whereas deb only allows pkgs.

I think the times I tried to install an rpm were with a one-off rpm (not from a repo) built for that distro.
I’m not confusing urpmi with rpm. rpm pkgs specify general reqs (eg requires usb-hotplug). This req may be satisfied by more than one pkg in which case the manager will prompt the user to choose an option. AFAIK, most managers don’t check the user’s choice against the rest of the deps, direct or not. They blindly install the choice and then continue. All goes well with this install. Now suppose the user goes to install another pkg that deps on usb-hotplug but alsp deps on usb-somethingelse. usb-somethingelse is only available in one package and that one package also provides usb-hotplug. The manager won’t let 2 usb-hotplug pkgs be installed so it ****s off and leaves the user to sort it out. This phenomenon is colloquially known as rpm dependency hell. This is possible because rpm allows both deps on specific pkgs and provides whereas deb only allows pkgs.
I’m not saying it’s not possible to get into a deb dependency hell, it’s just a bit harder. This is all coming from 5 year old memory though.

So what do you think? Do these issues he’s describing still persist? Is it an rpm design issue or was it just a package manager issue?

P.S. I hope this was the right section to post this under. If not I apologize.

Whoa sorry about the profanity - I thought it’d be alright if it was censored. I really apologize.

Can’t find the edit button…

Yeah they locked this instantly on Fedora forums even though they were edited out

On Tue, 05 Oct 2010 22:36:01 +0000, YoshiroShin wrote:

> So what do you think? Do these issues he’s describing still persist? Is
> it an rpm design issue or was it just a package manager issue?

More of a package manager issue, if you use zypper or YaST to do the
install of an individual RPM, the dependencies tend to be installed, as
long as the packager defines them properly.

I expect that it would be entirely possible to create a DEB that had
dependency issues as well. If the packager follows the standards for the
distro, then it should work regardless of what file format it is.

This is one of those ‘religious’ wars I really don’t understand - just
like GNOME v KDE or Emacs v vi.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

“Still persist”? Nothing of what he said makes sense at all… not today not ten years ago. IMHO whatever problem it had, it probably wasn’t urpmi fault but his.

So rpm has a feature that deb misses… and somehow that’s a point for debs? But wait a second… deb also allows that!!! Debian Policy Manual - Declaring relationships between packages

Lets see…

$ rpm -q --whatprovides desktop-translations
bundle-lang-common-es-11.3-8.1.noarch
bundle-lang-common-en-11.3-8.1.noarch
bundle-lang-common-ca-11.3-8.1.noarch
desktop-translations-11.3-12.1.1.noarch

Oh, my god!!! My system has multiple installed packaged that provide the same (“desktop-translations”)… how much time I have before it explodes?!?

No, this is known as “since right now we don’t have an Internet connection available just say anything, nobody can verify it anyway”.

P.S. And yet another definition for “rpm dependency hell”… I think I counted 37?

Anyway here’s an addition (he didn’t read RedDwarf’s reply when he wrote this):

Him:
let them know that A) I was using a pkg mgr when I experienced my problems, B) it was some time ago so these issues have probably been resolved, and C) I do know what I’m talking about. I’ve used Mandriva (just after the rebranding) for >6 months and I’ve used Ubuntu for >1 year. [In other words], I’m not a newbie.
It’s the ability for RPM to specify capabilities that screws you. (contrived) scenario:
Pkg A(not installed) provides cap_1, cap_2. Pkg B(not installed) provides cap_1, cap_2, cap_3. You install Pkg C which requires cap_1+cap_2 and conflicts with cap_3. To satisfy the dependency, you choose Pkg A. All goes well. Later, you choose to install Pkg D which requires cap_1+cap_2+cap_3. Now you’re [in a not too good position] if you need both C and D installed as they’re mutually exclusive.

More thoughts? I’m only doing this as it’s a learning experience for me and he might find this conversation constructively stimulating.

Yes, in that example you can’t install both C and D… that’s exactly what the packagers wanted, what’s the problem? But notice this example adds the “conflicts with cap_3” part. This has nothing to do with “provides” but with “conflicts”.
Two packages aren’t supposed to be installed at the same time and RPM doesn’t allows you to do so, RPM just saved the day avoiding whatever problem exists when both packages are installed at the same time.

Another question is if there is really any real world situation where that can happen. But if it were, RPM would do the right thing. Or you really want RPM to allow two conflicting pieces of software to be simultaneously installed without a warning?
Anyway, the same thing would happen with debs… that yes, also support “conflicts” (7. Declaring relationships between packages — Debian Policy Manual v4.6.2.1)

When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be installed on the system at the same time.

In short, your friend doesn’t have a clue, what he is talking about.

This can be seen easily by him comparing rpm with apt (which he does several times).

  1. RPM and DEB are just package formats

  2. If at all, rpm (the program) should be compared to dpkg, they are the “low level” package managers, and no, none of them resolves dependencies.
    Even better, my last experience was slightly different, when using dpkg on a system, which was not connected to the internet (yet) to install some software needed for getting it online (at least for the user who would use it later). So i used dpkg in the same manner as I would have used rpm, giving it an install instructions and knowing it would fail, but getting the needed dependencies from the error output (which is always quicker than using apt/zypper especially on offline systems). Instead of denyig installation and telling me “missing dependencies, can’t do that” (which I would call a sane way), dpkg actually started the installation of the package and puked afterwards with missing dependencies on configuring the package.

  3. Both zypper and apt are “high-level” package manager, which resolve dependencies.

I know for sure, that zypper (and before zypper YaST also did it) is able to install a local package and resolve needed dependencies automatically if they exist.

I am surprised that apt can also do this now, last time I tried (which, to be honest, is some time ago) I could not do it.

However, the possible reason for that, I don’t know apt very well, and maybe that’s the real point of this whole thing, your colleague obviously doesn’t know other package managers well, the only difference, I don’t blame apt for my potentially missing knowledge of how to use it.

I am very greatful for you input. I’m having a much tougher time on the Fedora forums - they get defencive easily. If my colleague has more to say I’ll post it. Otherwise, thanks.

It is just a personal experience, but I switched to OpenSuSE last November and one of the main reasons was the package management.

But I don’t think that OpenSuSEs package management functionality could not be achieved with the deb package format, it is more a thing of difference in supporting tools and services like zypper/apt, yast/synaptics and obs/launchpad. I think users won’t notice if OpenSuSE now starts using deb instead of rpm and the same goes the other way around. You won’t notice a difference when Debian starts using rpms. At least, theoretically as the community would get pretty hot on that topic and the transition itself will of course cause heavy problems, which is a good reason Debian won’t switch to rpm anytime soon to help unifying Linux a bit more.

Him:
I’m well aware that rpm package managers are better than they were 5 years ago. I just don’t care to use them because I don’t like the way rpm works re: capabilities. It’s a nice idea in theory but in practice, you get situations like the contrived example.

@RedDwarf: I know rpm does the right thing and stops. So would dpkg (only after attempting to install. I agree, not the greatest idea). It’s the way I have to navigate among the options that I don’t agree with. Many times I was presented with a couple of options and chose the option that provided the capability I needed only to find out that it conflicted with some other random package. If it’s gonna conflict at some point, why offer it? When I’m using standard repos, things like this shouldn’t happen. I fully understand that as soon as I go and install random rpms not in the repo I’m risking dependency resolution hell.

@Akoellh: I fully understand that rpm and deb are package formats and that urpmi/yast/synaptic/apt are managers. I am not confusing the 2. I have >6 months experience with both of the formats and their managers. I have used dpkg and I have used rpm. I have also used yast and synaptic. I know the difference.

I don’t think his mind will be changed anyway. If he prefers deb then so be it I guess. I myself don’t really care as long as it handles what it’s supposed to handle well.

Here he is just saying the same than in

tl;dr rpm allows reqs specified as pkgs or provides (a capability, file, etc) whereas deb only allows pkgs.

but with other words. And I already answered that…
I think I made it perfectly clear that “the way rpm works re: capabilities” is EXACTLY the same than “the way deb works re: capabilities”. I gave a pretty link (Debian Policy Manual - Declaring relationships between packages)… he will need to read if he wants to talk about “theory”.

This part is really soooo wrong…

  • “the way I have to navigate among the options” is obviously a manager topic, not a RPM one. And how he changed from a root deep RPM philosophical problem to a cosmetic one???
  • “If it’s gonna conflict at some point, why offer it?”?? The list of offered options is again, obviously, manager dependent. And no, I don’t think any manager will do such a thing.
  • What options?? In the example he gave there are only two options. When he tries to install package D the manager will ask if he really wants to, even if that will require to remove package C, or if he wants to cancel the installation of package D. “Do you really want to install D?” Yes or no, that’s the only question the manager will ask.

But that’s not OK. At this point the situation is SOOOOO CLEAR that to continue defending his position can only be explained with some kind of learning disability (I’m very serious here) that perhaps could be treated.
All his argument is based in two proven false assertions:

rpm allows reqs specified as pkgs or provides (a capability, file, etc) whereas deb only allows pkgs.

and

The manager won’t let 2 usb-hotplug pkgs be installed

Alrighty then. I think I’ve learned about all I want to learn from this (at least this way anyway). If he wants to respond I’ll tell him to do it himself. I don’t really feel that great keeping this argument going because now it’s gotten to a “he’s wrong”, “no, he’s wrong” thing and regardless of who’s right, people are beginning to have their nerves tested.

Well thank you very much guys for taking the time two put in your two cents for the topic. I’ve learnt a bit and that’s primarily what I wanted. Unless anyone actually wants to continue I think that’ll be all. Take it easy.

I kind of liked urpmi i and urpm e but currently the distro that really used that is dead to me.

A package is a package. A manager is a manager. Some suck some don’t and some just keep getting better/

I use YAST quite happily zypper not so much. apt and synaptic as necessary. I find apt easier to use but am not a GNU zealot so I don’t use Debian much.

I didn’t just said “he’s wrong”. I gave a link to Debian official docs to disprove his first assertion and showed a real example in a real system to disprove the second one.

Either the Debian docs and the reality is wrong or he is wrong. Who’s right is beyond question.