Mailinglist Archive: zypp-devel (64 mails)

[Jiri Srain <jsrain@xxxxxxx>]

Dne Saturday 12 of July 2008 04:02:41 Duncan Mac-Vicar P. napsal(a):
> I have implemented the basics for feature #301904, which calls for
> having a way to detect that a repository may be outdated.
>
> http://en.opensuse.org/Standards/Rpm_Metadata#Outdated_Metadata_Hint
>
> I am citing what I documented there:
>
> Joe user has an update repo pointing to a mirror directly (no
> redirector). The mirror goes out of sync (however it is still
> reachable). He does not receive any warning, and meanwhile the main repo
> has lot of updates.
>
> The server will have a hint on how often the metadata is regenerated due
> to a change. The client could detect this and hint the user that the
> metadata has not been updated since long time. It is responsibility of
> the server then to update the timestamp of the files if there are no
> changes in the expire time the repo administrator decided for his own repo.
>
> The value is only a hint. The user should be able to disable or alter
> it. (global in zypp.conf and per repo in the .repo file)
>
> Implementation
>
> An attribute "expire" is added to repomd section:
>
> <repomd expire="100000">
>  <data type="primary">
>  <location href="repodata/primary.xml.gz"/>
>  <timestamp>342423423</>
>
> Originally in the first proposal, the timestamp was another attribute,
> but now I calculate it as the newer timestamp of all the resources
> listed in the repomd.xml file.
>
> This enhances zypp::Repository class API as follows:
>
> zypp::Date Repository::generatedTimestamp() const;
> zypp::Date Repository::suggestedExpirationTimestamp() const;
> bool Repository::maybeOutdated() const;
>
> This can be used by applications to check whether a repository is
> "dead". However we could as well implement easier hooks for applications
> to receive a report, or signal.
>
> The actual implementation is to read the values from repomd.xml and
> merge them in the .solv file as an extra attributes from the extra
> non-solvable number -1.
> (which is tricky, as if there are deltarpms for example, there will be a
> deltarpm data in position -1, but we don't care as the rpm reader don't
> look at them ), may be Michael Matz can comment if my approach is ok.
>
> And of course, there is a testcase.
>
> Any feedback on how to mature this, welcome.

I like it, IMO it does exactly what user may expect.

I just added the perhaps obvious requirement to regenerate the metadata before 
it expires even if there is no change.

Jiri

-- 
Regards,

Jiri Srain
YaST Team Leader
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                             e-mail: jsrain@xxxxxxx
Lihovarska 1060/12                             tel: +420 284 028 959
190 00 Praha 9                                 fax: +420 284 028 951
Czech Republic                                 http://www.suse.cz