[Rpm-maint] RPM 4.9.0 alpha available

[Panu Matilainen]

On Thu, 25 Nov 2010, Michael Schroeder wrote:

> On Thu, Nov 25, 2010 at 10:48:08AM +0200, Panu Matilainen wrote:
> > If you have time to look at the more than one tilde-case, then please do. 
> 
> Okey, I'll send a patch later this day.

Cool.
 
> > 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...
> 
> Agreed.
> 
> > > 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.
> 
> Yes, that's what I meant. Makes 'rpm -q --recommends' a lot easier, too.

Yup, it'd make some things easier, other things .. well, not harder 
exactly, just more verbose perhaps (in code).

> > 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)
> 
> The current suggests/recommends has a clear semantics (at least in
> the zypp stack): recommends are pre-selected, suggests are just
> listed. I think making this more complicated will confuse users
> even more.

Yup, that's the "obvious" semantics for them. I didn't mean exposing 
1-9999 levels of choice for the users either, but more of an internal 
presentation of the data. But using entirely separate tags for the 
variants would have its advantages.

> > 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...
> 
> Now that you mention it, I think one of our Czech developers
> suggested that feature on the mailing list. But I don't remember
> the use cases for that feature.

With those tips I managed to find it: 
http://lists.rpm.org/pipermail/rpm-maint/2009-September/002495.html

	- Panu -