Fedora 7 Launch

Michael Schwendt bugs.michael at gmx.net
Sat May 12 18:23:00 UTC 2007


On Fri, 11 May 2007 14:21:43 -0400, Luke Macken wrote:

>     o Repo cleaner.  We need something like RepoPrune.py/fedora-updates-clean
>       to run occasionally and clean up our tree.

There's also repomanage, ready to use:

  $ rpm -qf $(which repomanage)
  yum-utils-1.0.3-1.fc6

It has been used for a long time for Extras, but only solves one part of
repository maintenance. Another part, that remains, can get tiresome and
error-prone, especially when no package db is available (one reason why
repoprune took over and also one reason why I like kojira).

Everywhere repoprune has been mentioned or derived so far it has been
misunderstood. It does NOT do the same as repomanage. It is not designed
to do exactly the same. The reason it is approximately four times faster
is that it does something else, something more rigorous and more helpful.

So, what technique/tool to use is a repository-design decision. If for
every binary rpm in a repository there MUST be a source rpm in a
corresponding repository, repoprune can do its job really well and prune
those repositories. Where the requirement isn't met, repoprune cannot
be used. For Fedora Extras, the requirement is met.

In the interface, repoprune needs to know about:

 1) root path to source rpms directory
 2) root path to corresponding binary rpms directory
 3) how many different builds of each package to keep
 4) a white-list of source package %{name}s to ignore

Repoprune then deletes old source rpms in pass one. In pass two it deletes
any binary rpm that refers to a non-existant source rpm. If necessary, I
could think of making 3) a map, which would make it possible to configure
the number of builds per %name.




More information about the infrastructure mailing list