Mailinglist Archive: zypp-devel (116 mails)

[Jan Kupec <jkupec@xxxxxxx>]

Duncan Mac-Vicar wrote:
> On Wednesday 20 June 2007 17:56, Jiri Srain wrote:
>> Hi!
>>
>> This is my suggestion on how to define the refresh policy with refactored
>> ZYPP:
>>
>> We need to keep the information when last a source was refreshed in order
>> to decide whether a source needs to be refreshed or not. In addition, we
>> will need some policies defining whether a source should be refreshed or
>> not.
> 
> RepoManager has a RepoStatus query with timestamp and checksum both for 
> metadata and last cache build. I think I made them private.

As i suggested in other post to this thread, something like
RepoManager::isUpToDate(RepoInfo) would be nice.

Also what happens if network or particular repository is not available
at refresh time?

I believe it is solved by the fact that application is responsible for
calling refresh on each known repo by itself and handle exceptions for
each of the call by itself. So that in the above cases, it just catches
exceptions prints a warning and continues with next repo, right?

>> 2. Tools which should install a package. They should work as fast as
>> possible. we can pay the price of installing package which already has an
>> update at least in some cases.
> 
> This assumption is false in most cases. If the metadata is old then what will 
> happen is that you will solve a old package that will probably match (because 
> packages usually doesnt change dependencies often), but the link (filename) 
> will be wrong and the package will fail.
> 
> This exposes a failure in metadata design, only updating the filenames will be 
> a quite option for the use case you mention.
> 
> Your usecase works if the repo keeps the old version of the package as well 
> (or more).
> 

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