[Rpm-maint] RPM 4.9.0 alpha available

[Michael Schroeder]

On Mon, Nov 22, 2010 at 03:18:46PM +0200, Panu Matilainen wrote:
> On Fri, 19 Nov 2010, Michael Schroeder wrote:
> > - 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
> http://rpm.org/ticket/56#comment:6 

Yes, should I create a new patch?

> > - 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 
> alone...

Yes, that also worries me. We could define a provides() namespace to
tell rpm to look at provides, but I'm not sure if it's worth it.
(This provides() might also be used to make obsoletes work on
provides instead of names, which might be useful in some rare cases.)

> 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: 
> http://lists.rpm.org/pipermail/rpm-maint/2010-June/002766.html 
> http://lists.rpm.org/pipermail/rpm-maint/2010-June/002787.html 
> Comments/ideas would be welcome.

Yes, I followed the threads but didn't look depply into the patches.

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

Well, "should" is a bit too strong, it's more like "nice to have". As rpm
is free to ignore them it is no error to ignore them in the ordering process.

> (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 
> RPMSENSE_MISSINGOK.

That's just some historic thing. At the time I did the SUSE patches, the
SUGGESTS/ENHANCES tags were already reserved and I hijacked the old
RPMSENSE_PATCHES flag used for patchrpms. Thus I didn't need to reserve
new bits/tags.
It would be much cleaner to put the "strong" versions in new tags.

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

I agree that "reverse requires" are strange and should not be supported
The weak versions are mostly "hints" to the layer on top of rpm, that
say that if package A is selected it's good to also install "B". Useful
for anything that looks like a plugin, be it codecs, kernel drivers,
language packages, ...

> > - 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 zypp stack currently doesn't store such information.

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

An extra header is probably a bit overkill to store a simple integer
(although this seems to be the most flexible approach).

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}