Re: update patch, take 3
Mike McLean <[email protected]>
| Newsgroups | gmane.linux.rpm.metadata |
|---|---|
| Organization | Red Hat |
| Message-ID | <[email protected]> |
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.