Mailinglist Archive: zypp-devel (148 mails)

[Michael Matz <matz@xxxxxxx>]

Hi,

On Thu, 27 Mar 2008, Josef Reidinger wrote:

> - keep support of regexes in the locks file - have function which does
> something like locks coverage. How would it work? It would get old locks and
> resolvables which the user wanted to lock (including the changed ones). Then,
> for each lock it gets all matching available resolvables and checks if the set
> is a subset of currently locked resolvables. If it is, those resolvables are
> marked as already locked (written/covered/whatever) and the lock is written
> back to the locks file unchanged (meaning if it was a regex, it will stay so).
> Thus the remaining resolvables will be written to the locks file individually
> (without using any regex).
>
> This may not be trivial.
>
> - drop regex support and write one lock per resolvable

This doesn't work.  Suppose you have a lock matching "a*", then it 
currently applies to a certain set of solvables (those starting with 'a').  
If you write out locks for exactly that set you miss the case if the user 
installs another package starting with 'a'.  The old lock would have 
applied to it, the set of new locks wouldn't anymore.  Not to talk about 
the waste of course.

Perhaps the two file idea is the cleanest.

OTOH I don't really see the necessity of two files.  Suppose again there 
is a "a*" lock that zypp loads (and remembers, so it also can be stored 
back).  Further suppose that the user now explicitely locks a package 
abcde (matching the regex lock).  There's no reason why zypp should also 
store that lock too (so that in the end the lock file will contain "a*" 
and "abcde").  By this way you don't need to become overly fancy in order 
to not store superflous locks (i.e. I want to say that the complication in 
your first point seems unnecessary to me).


Ciao,
Michael.
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx