Mailinglist Archive: zypp-devel (148 mails)

[Josef Reidinger <jreidinger@xxxxxxx>]

Michael Andres wrote:
> I'd sugest to imporove PoolQuery, so it is able to be constructed from 
> some string representation (e.g. a line in zypp/locks). Nice if each 
> query is as well able to save itself in a human readable reparsable 
> string. Otherwise things are reimplemented in Lock and still missing in 
> PoolQuery.

Yes, good idea. I look at it and query looks good and reusable. Only 
suggestion, why is used repo_search in implementation? Is not possible 
use search through pool and use its indexes which can have better 
performance? (when ui generate 300 per name locks and then search all 
repos (when you don't set repo restrict) looks quite slow for me)
some string representation which I think can be useful

symbol separated fix collum - like name;Version;Kind
        advantage -
                small, easy, good to use with cut
        disadvantage -
                not flexible, bad to update, need know what each collum mean

LDIF format - atribute name comma value, records separated by blank line 
(ui often generate only one line name at the easiest case)
example:
        name: foo
        version: ==4.2.3
        kind: patch
---end example

        advantage -
		easy to change attribute without backward compatibility break, good 
readable also when you see first time this string
        disadvantage -
                lot of data, file can be large, cannot use in log (in my way)

LDIF oneliner - all atribute in one line. e.g. name:foo version: ==4.2.3 
kind: patch
        advantage -
		same as LDIF, maybe worse readable by human, can used in logs, not too 
much screens when you look at it
        disadvantage -
                worse readable

xml - I think everybody know it. Not so easy to parse.

I think that best is LDIF to output and oneliner LDIF to log (xml is not 
human readable, I think only crazy people want read more then one screen 
xml output :)

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

> ---
>
> > Other issues:
> > - how to clean up or maintain the locks file, it will probably be a mess
> >   after some time
>
> We provide some interface to maintain the lock file.
>
> - list all rules
> - list items covered by a rule

yes, this api cover it...only need decide how many this function is used
list all rules - save locks queries or reread it each time?
list items covered by a rule - only execute on query, not?

> - maybe track the last time the rule matched somthing:
>
>         yast2-packagemanager:
>
>           This rule did not match any item for more than one year.
>           Do you want to keep int anyway?
>
>         yes     no

where store this? how often save it? what to do if someone install one 
time per year?
When user remove repository and for example 30 filter is no not 
matching...isn't confusing if user after year gets this question after year?

> > - the locks file format will be extended to include resolvable kind. The
> >   question is whether we want to support also something else
> >   (architecture, vendor, ...)
>
> Whatever a PoolQuery is able to understand ;)
>
>
>
> > - the API supports locks file <-> pool manipulation as well as direct
> >   to/from locks manipulation, is it OK?
>
> I somewhat dislike the approach, that each application is responsible for 
> reading and (re)applying the locks to the pool.
>
> If we want to support a global lock file /etc/zypp/locks, there could be 
> some option turning zypp.lock support on/off. But if it is on, the pool 
> which is responsible for building the transaction should be responsible 
> for reading and (re)applying the locks. 

so locks communicate only with pool except for some question on locks 
and locks maintain?

> If we'd have PoolQuery that can be serialised to, and reparsed from, a 
> string, we have a versatile object. 
>
>
> We can provide some query editor that displays a set of queries.
> Supports adding/removing/editing the queries.
>
>
> This editor can be used to maintain the queries retrieved from zypp/locks.
> The result is written line by line into /etc/zypp/locks.
>
> This editor can also be used to maintain named queries (if) the UI allows 
> the user to define (them). Those named queries could be saved in some 
> different (ini)-file. Those queries could be shared with zypper
>
>          zypper query 'installed_last_week'
>
> ...
>
> A lock is a query, and it's result serves a special purpose.
>
> A lock is not a special query.
>
>
>
>
>
>
> -----
> c++ related:
>
>   /**
>    * removes all locks in container from file
>    */
>   template <class Container>
>   void removeLocks( Container &container ) const;
>
>
> ( If Container itself is not modified pass a 'const Container &'. )

yes, I forget it. good mention

> - Your interface should (always) be iterator based (maybe a container
>   interface for convenience):
>  
>   template <class Iterator>
>   void removeLocks( Iterator begin, Iterator end ) const;
>
>   template <class Container>
>   void removeLocks( Container & container ) const
>   { removeLocks( container.begin(), container.end() ) }
>
> Look ar classes like the sat::Pool or ResPool, they have a couple of 
> iterators:
>
>         sat::Pool::reposBegin()
>         sat::Pool::reposEnd()
>         sat::Pool::solvablesBegin()
>         sat::Pool::solvablesEnd()
>
> and a plain array like 
>
>         int val[] = { 1,2,3,4 };
>
> has no begin()/end() methods but Iterator
>
>         void print( int );
>         std::for_each( val, val+(sizeof(val)/sizeof(int)), print );
>
> Iterator is the most versatile item here.

InputIterator have problem, that don't ensure validity after increment, 
so you can only onetime iterate over input iterators. So when use 
container you have more implementation freedom. It's trade off versatile 
for possible more time iterate (this can sometime help).
In rest of libzypp code is used iterator, so I use it also.

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