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 - _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint