[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