[Rpm-maint] RPM 4.9.0 alpha available

Panu Matilainen pmatilai at redhat.com
Mon Nov 22 13:18:46 UTC 2010

On Fri, 19 Nov 2010, Michael Schroeder wrote:

> On Fri, Nov 19, 2010 at 12:00:48PM +0200, Panu Matilainen wrote:
> > We're closing in on another major RPM release, and compared to 4.7 and 4.8 
> > the number of changes is so much bigger that we're starting with an alpha 
> > release instead of going directly to beta, just in case.
> As we're doing a major release, what are your thoughts on the
> following features:
> - tilde support in version comparison

No fundamental objections, it'd simplify packaging of pre-release versions 
a great deal. The current suggested patch has some issues though, see

I dunno if the compatibility aspect is worth worrying about too much.
There might be a handful of packages using ~ in version/release in 
the wild but common it is not, and it probably wouldn't be the end of the 
world if those got "broken". Still it needs to be at least considered, 
even if the decision is just to ignore.

> - triggers on provides instead of package names

I dread to think what would happen for the existing triggers when they 
start hitting compatibility provides (provides added on package renames / 
replacements). Me thinks it's best to leave the existing trigger semantics 

The new "collections" feature behaves largely like named virtual triggers 
and as it's a new mechanism with an opt-in behavior, it's "safe" from 
compatibility point of view. It will be experimental-only in 4.9 initially 
though as various open questions and issues remain, at least some of them 
can be found in these threads: 
Comments/ideas would be welcome.

> - weak dependencies (basically just parsing them and storing them
>   in the rpm header)

Yup. It's something I keep kicking around every now and then and ending up 
not feeling happy enough to commit. The thing is, as soon as we have weak 
dependencies, rpm will need/want to deal with them to some extent - at 
least ordering should be aware of them (and then there's the long-standing 
request of allowing ordering requests without declaring strict 
dependencies which is a sub-case of weak requires)

One thing that bothers me with the existing patches is using another bit 
of the already scarce resource of rpmdsFlags bitfield for something that 
doesn't actually /do/ anything (the "strong" flag). I do realize changing 
that would be cumbersome for the existing users, but I'd rather put that 
data into a separate (integer array) tag and call it 
RPMTAG_SUGGESTSPRIORITY or such. Rpm itself should be fine with the 
knowledge whether a dependency can be ignored or not, ie the existing 

All in all, from rpm POV, weak requires are /relatively/ clear. The 
"enhances" side of things is another story: they're a weak version of 
something we don't have at (and probably dont want to have): reverse 
requires. Which makes the whole thing conceptually quite a platypus in 
rpm's world. Of course rpm is free to ignore them completely but...

> - defining some tag where yum/zypp/smart can store the reason
>   why the package was installed (user selected/dragged in via
>   dependencies), so that we can implement a "show me all unneeded
>   packages" function

I'm fine with adding such a tag, as long as its defined in a way that it 
can be used by all the relevant depsolvers. We seem to have a pretty good 
attendance from the depsolver camps this time around... so:

What such things are the depsolvers currently storing in their own 
databases, and in what format? The "reason" tag would seem to me to be an 
"enum" type basically (explicit request or dependency), so it'd be an 
integer in the header with some predefined RPM_FOO_* constants as its 

The other aspect is the "how" part: from C/C++, it's possible to add tags 
to the header from the transaction callback, but that wont work from 
python bindings at least. And also the callback is not a very friendly 
environment to do anything in any case... so it'd probably want some 
entirely new interface. I've a patch floating around someplace which 
permits transaction elements to carry an "extra tags" header which is 
merged to the actual package header at install time, but that's not 
necessarily the best approach either.

	- Panu -

More information about the Rpm-maint mailing list