[Rpm-metadata] update patch, take 3

Mike McLean mikem at redhat.com
Tue Mar 27 21:24:07 UTC 2007


Hans-Peter Jansen wrote:
> This sounds like a promising idea, but I would rather make it the default 
> behavior in case meta data exists, as I don't like the notion of 
> semantically separating initial setup and update modes. Consider my case: 
> I'm mirroring many different repos (via rsync) and that python script is 
> smart enough to call createrepo after rsync. Your update mode would force 
> me to handle the initial setup case separately :-(.

We may want to hold off on making it the default, just in case some 
unforeseen situation causes problems with the code. Don't get me wrong 
-- I've run many tests and we've used this code internally for several 
months, but our setups may be less varied than those of the broader 
createrepo community.

Note that you can use --update even if there is no previous repodata. It 
will simply print a warning and proceed normally.

One thing we might want to do is give the option a short form.

> Wouldn't it also obsolete the cachedir option, if the meta data could be 
> regenerated from the repodata directly?

Somewhat, it depends on the situation. It is conceivable that someone 
may have a setup where many repos share a cachedir. If a package is 
added to repo A but had already been present in repo B (and hence in the 
common cachedir), then --update alone would have to calculate the 
checksum of the new rpm (because it was not in the old repodata), but if 
a cachedir was in use then the saved checksum would be used.

Note that you can use both options and get the best of both worlds.



More information about the Rpm-metadata mailing list