-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Duncan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkh4EMEACgkQzR62qWZ+QtGhpwCgmcugRResmxRlSmcOjGWegtl4 DswAoK+DIcsfuXdovOtziwgND+4Ie18D =+PSa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org