Mailinglist Archive: zypp-devel (227 mails)

[Josef Reidinger <jreidinger@xxxxxxx>]

> > > ---
> > > Need to recheck locks when new items are added to the pool:
> > > We can either
> > > - make the restored lock-queries available to the pool (or
> > > - we need some signal if the pools content changes)
> > > ---
> > > We can make a 'waslocked'-bit availabe in the ResStatus, to remember all 
> > > solvables covered by a lock-query. Later in commit we can check whether 
> > > there are solvables:
> > > - locked but not 'waslocked' (lock added by UI)
> > > - 'waslocked but unlocked    (lock removed by UI)
> > > Locks added by the UI are treated as name-locks ("foo", not "foo==1.2.3").
> > > These could be added to <targetroot>/...zypp.locks.
> > > Locks removed added by the UI are simply ignored. But we could remove any 
> > > exising name lock, then the package will in fact be permanently unlocked, 
> > > if no complex rule matches it. (no regex no cry).
> > > If I want to lock 'kde*' but not 'kden', I have to refine my regex.
> > I don't understand this. So when ui remove lock added from locks file, 
> > remove it at end also from locks file(and generate for other locked package 
> > from regex ui simple lock) or don't remove it and user must refine his 
> > regex?
>
> The UI(single package selection) should only add/remove name-locks 
> (name:foo, no other condition) when toggeling the status.
>
> If such a lock is to be 'removed', we'd remove a lock (name:foo) if it 
> exists. Unless the package is also hit by a more complex lock, it will 
> appear unlocked next time.
>
> If there is a 'complex' query that hit the package (name:f*o), the package 
> will continue to be locked until the user changes the 'complex' query.

Maybe better for easier detect ui (created libzypp, not handy by user) 
lock can be special attribute added to query which has also be written 
to file during serialize and libzypp after session (or after confirm 
lock etc.) can remove only query with this argument. So ui can use more 
complicated locks ( I think it create it, for example name and 
kind...maybe also repo...whatever ) and is easy recognize who make this 
query. And users lock can be removed only handy by user (of course some 
warning for users, that this behavior is used).
somethink like
manually generated: yes|no (default no...we can secure that we write 
only yes).
maybe this can be also used in future for some query history (user can 
write own query which doesn't remove libzypp from history) so he can 
store install result of his own query (f.e. he is developing and need 
last version of some libs so he can write manual query and then only 
each week write something like zypper up --query myquery and update only 
result of this query....hmm...only idea for future use

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