Skip to content

Compat options [Proposal]

Tomas Mlcoch edited this page Feb 17, 2014 · 2 revisions

In some situations, behavior of original createrepo is not optimal and it is based on hacks.

Currently createrepo_c tends to mimic these behavior patterns. But I feel that this is a bad approach. So in the next release of Createrepo_c some behavior will NOT be more incompatible with original createrepo by default. But there will be introduced some compat options that enable compatible modes that enforce the original (bad) behavior.

Original createrepo misbehaviour

Weird management of old metadata during --update

During update with --update option, the original createrepo removes: primary.xml, filelists.xml, other.xml and their sqlite equivalents primary.sqlite, filelists.sqlite, other.sqlite. But any other metadata stay untouched in the 'repodata/' directory!

This situation is even more awkward, because such retained old metadata files are not listed in repomd.xml and just reside in the repodata/ unreferenced.

So for example: if you do a repo update every week, and during every update you add a new comps file (--groupfile), then after few weeks you will have a bunch of comps file in the repodata/ directory. Because nothing (except the above listed metadata files = primary, filelists, others and their sqlite equivalents) is removed!

Createrepo_c behaviour:

By default, during update (--update) all metadata listed in the repomd.xml will be removed. This behavior can be changed by --retain-old-md which, if used, leaves all old metadata files in the repodata/ dir.

Idea of this solution is that run of createrepo_c or createrepo_c --update should provide same results = The content of repodata/ should be the same.

A little deviation from the idea is that createrepo_c keeps in the repodata/ directory all files that are there but not referenced by the repomd.xml. Its because the createrepo_c don't want to destroy data that user could put there by some mistake.