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@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz