[Rpm-maint] RPM 4.9.0 alpha available

[Panu Matilainen]

On Wed, 24 Nov 2010, Michael Schroeder wrote:

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

If you have time to look at the more than one tilde-case, then please do. 
As for the compatibility tracking and all that: looking at the options, 
it'd probably only create a much bigger mess than just slipping it in 
quietly. It's not as if meaning of '.' is getting redefined...

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

I'd say lets see how the collections thing pans out. It's not going to be 
"ready" in 4.9.0 but once 4.9.x is branched I intend to get back to it and 
hopefully it can be backported to 4.9.x once deemed stable.

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

Yeah.. but adding at least the soft requires into ordering is pretty 
trivial. Reverse (soft) dependencies might be more involved but shouldn't 
be much of a problem (although I haven't really looked into it)

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

Nod. Wouldn't be the end of the world either, I'd just rather think of 
the slot RPMSENSE_PATCHES left as a free bit for something that absolutely 
/must/ be in the dsflags.

> It would be much cleaner to put the "strong" versions in new tags.

Okay, if you can live with a transition phase where the "strongness" moves 
to a separate tag from being a dsflag then lets put the 
strongness/priority-thingie to a new tag.

Mm.. or do you mean having new RPMTAG_RECOMMENDS* etc triplets for the 
"strong" versions? Thats of course one option too. I was thinking more of 
a new integer array tag that adds "priority" to each dependency, which 
could express more levels than just weak/strong hint. (and in theory, 
perhaps, could be used for hard requires too: eg if there's a dependency 
loop that needs cutting then prefer the higher priority dependency)

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

Yup. Although reverse requires would have their uses - not in the world of 
distributions, which are in control of their packages, but for third party 
repositories and packages. I remember wanting reverse dependencies more 
than once in my previous job: things like customization packages for 
software A which should be pulled in anytime somebody installs A from the 
repositories.

Also I seem to recall a discussion/comments regarding reverse obsoletes, 
where a package could declare itself being obsoleted by something else 
(ObsoletedBy: foo). I thought it was in the "problems" pages in rpm.org 
wiki but can't seem to find it...
 
> > > - 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.

Ok.

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

For a single integer it'd obviously be a huge overkill, but at least yum 
already has several other items too it'd like to store in rpmdb (see 
Seth's reply). Adding separate API calls for any new additions seems 
silly, and when dealing with more than one type of data that will 
end up in the headers .. using a header for the extra tag manipulation 
is by far the simplest option.

	- Panu -