A report from the RPM summit [LWN.net]

A report from the RPM summit

Posted Oct 8, 2009 18:59 UTC (Thu) by joey (subscriber, #328)
Parent article: A report from the RPM summit

Just a quick look at their planned features compared to what's in dpkg
already:

Virtual triggers

Not supported by dpkg, I think. In the dpkg world, this would probably be
handled instead by the providers of the virtual package manually
triggering via dpkg-trigger(1).

File triggers

Supported by dpkg for a bit more than 1 year now. And it rocks.

Funnily though, their motivation is getting rid of ldconfig calls -- and
we were unable to get rid of them in debian using dpkg's file triggers.
RPM's file trigger syntax will need to be more expressive than dpkg's for
this to work. (We stopped worrying about this when ldconfig got a second
level cache that made it very fast to run.)

Soft dependencies

Supported by dpkg for 15 years or so, and Recommends are used by apt-get
and aptitude for a couple of years. (But dpkg does not have a Supplements
-- I don't know how that differs from enhances.)

Update scriptlets

Dpkg does not have separate scripts for upgrade, but I think its
arguments passed to the regular postinst and prerm are slightly saner
than rpm's.

Scriptlets arguments

Not enough detail to say for sure whether dpkg's arguments allow doing
everything this will do. Their example *can* be handled by the arguments
dpkg passes to a postinst. But it sounds like a lot more info may be
included.

DeltaRPM

(Looks like this won't be added to rpm yet.)

New payload format

Wow, switching from cpio to something else will break a lot of cheezy
rpm2cpio type scripts. Curious that they do not consider tar an option.
Maybe because tar has differing semantics than rpm with respect to
whether parent directories have to be included?

Tilde in version

Added to dpkg several years ago. Not clear if their chosen meaning for
tilde is compatible with dpkg's. (But IIRC, dpkg and rpm version
comparison is already not fully compatible.)

Easy way to add or remove autogenerated dependencies

Debs are built so much differently that there is really no way to
compare.

Logging and recovery

Sounds interesting.

(Log in to post comments)

A report from the RPM summit

Posted Oct 9, 2009 0:35 UTC (Fri) by joey (subscriber, #328) [Link]

Sure, but it doesn't records transactions and allow rollback, which is what rpm seems to be aiming to do.

A report from the RPM summit

Posted Oct 8, 2009 22:21 UTC (Thu) by nevyn (subscriber, #33129) [Link]

Wow, +10 karma for trolling. But then given your rpm vs. dpkg "comparison", I guess it shouldn't be too surprising.

I'll try and given non-flamewar-escalating responses, but you've made it pretty hard.

> > Soft dependencies

As the article says, see: http://en.opensuse.org/Software_Management/Dependencies

SuSE have had them for a while, the biggest problem IMO is how much they suck in practise. For instance you often want to suggest different packages depending on if you have a KDE or GNOME spin, etc. And given that rpm isn't going to do anything with them, putting them in the package instead of in the repodata. is likely not the best thing to do.

Having them in the package might be better than not having them, maybe.

> > DeltaRPM

> (Looks like this won't be added to rpm yet.)

This is just about where the code lives, and if there can be any code consolidation. deltarpm support has been in Fedora for ~6 months and in SuSE a lot longer, AIUI.

> > New payload format

> Wow, switching from cpio to something else will break a lot of cheezy
> rpm2cpio type scripts.

The summary at sitk.gk2.sk was probably worded badly, however the recent message on the rpm ML makes it clearer that the likely way forward is to have a cpio variant with larger fields ... used only for those rpms that need it.
One obvious benefit being that GNU cpio would also support this larger variant, and thus rpm2cpio would still work for all packages.

> Curious that they do not consider tar an option.

Same reason everyone else hates it, the format itself is horrid and GNU tar doesn't make it look more appealing.

> > Easy way to add or remove autogenerated dependencies

> Debs are built so much differently that there is really no way
> to compare.

Indeed, everything is hard coded. Which works fine if you have an infinite resource of packagers, less so for a company that is paying people to package things.

A report from the RPM summit

Posted Oct 9, 2009 0:50 UTC (Fri) by joey (subscriber, #328) [Link]

So, because I

a) Wrote alien

b) To keep things straight while doing that, wrote down an overview of some of the places package formats are similar/different, in a tabular form that was prone to being misunderstood, 10 years ago.

... I'm a troll. I see.

> Indeed, everything is hard coded. Which works fine if you have an
> infinite resource of packagers, less so for a company that is paying
> people to package things.

If you think everything is hard coded, I will charitably assume that you last looked at how debian packages are built a decade+ ago, before there were things like debhelper.

A report from the RPM summit

Posted Oct 9, 2009 15:35 UTC (Fri) by ballombe (subscriber, #9523) [Link]

... I'm a troll. I see.

No, you are just a new victim of a meta-troll , an old LWN fad...

A report from the RPM summit

Posted Oct 9, 2009 15:48 UTC (Fri) by nevyn (subscriber, #33129) [Link]

I don't believe I've replied to any of your comments.

In regards to my description of joey's comment ... sure, whatever. Next time there's an article on dpkg I'll respond implying that dpkg is just catching up to 15 year old rpm features, and dismiss everything else as pointless. Anyone who responds and doesn't agree with my tone will obviously be a "self righteous meta-troll".

Trolling?

Posted Oct 10, 2009 11:17 UTC (Sat) by man_ls (subscriber, #15091) [Link]

You get easily offended. I guess that what triggered your meta-trolling was the first sentence:

Just a quick look at their planned features compared to what's in dpkg already:

which I suppose may seem like derogatory or condescending if you have some sort of inferiority complex. You can also see it as "let's have a look at the planned features and see if they can usefully added to our package format". Probably there are some features in rpm that are not in dpkg, but that was not the subject of the message.

One of the requirements of trolling is to beg for attention, which was not the case here. The original message was also quite informative. Wait a minute, am I meta-feeding the meta-troll?

A report from the RPM summit

Posted Oct 16, 2009 15:30 UTC (Fri) by jschrod (subscriber, #1646) [Link]

I found joey's comment informative and useful. (And my primary systems use rpm and not dpkg, though I have a few Debian systems installed.)

If you think joey was trolling, you might want to get a life, some time in the future. It's an interesting and challenging concept, ready to be discovered, even by you!

A report from the RPM summit

Posted Oct 11, 2009 22:56 UTC (Sun) by jch (guest, #51929) [Link]

> Just curious: do debs have real multi arch support yet?

As far as I know, they don't.

There was some interest in adding that in the early AMD64 days, but as it turned out that it is quite possible to have a pure 64-bit userspace, interest slowly faded.

Right now, 64-bit Debian distributions are mostly purely 64-bit, with the few 32-bit packages present encoding their 32-bitness into their name (e.g. libc6-i386). It's not pretty, but it works fine in practice.

--Juliusz

A report from the RPM summit

Posted Oct 12, 2009 7:31 UTC (Mon) by niner (subscriber, #26151) [Link]

But that sounds like it wouldn't allow a crossgrade from 32-bit to 64-bit or back which is a
pity, especially with Debian's good upgrade reputation.

A report from the RPM summit

Posted Oct 12, 2009 11:14 UTC (Mon) by nye (guest, #51576) [Link]

You're right that it doesn't allow that directly, though it can be done with some work if you know what you're doing.

A bigger problem is that trying to run 32-bit binaries with non-trivial library dependencies on Debian is an exercise in pain. Debian's 32-bit support is *really bad*. Most libraries don't have 32-bit versions available, and those that do are just the binaries rammed into a couple of huge ia32- mega-packages.

There are proposals and frequent discussions about multilib, but no visible progress (unless you count major breakage for a month or so earlier this year), and it's one of those subjects which is practically guaranteed to start a flamewar if mentioned on debian-devel.