[csw-maintainers] A systematic approach to package renames

[Maciej (Matchek) Bliziński]

I'd like to return to the topic of package renames. I initially
described it here:

http://lists.opencsw.org/pipermail/maintainers/2012-January/015908.html

I think it's a great topic for a coding mini-project. The restful API
to the package database makes it easy to get the data. I would imagine
the utility working like this:

track-renamed-packages legacy dublin kiel [ more catalogs ]

Then for each combination of OS release + architecture, the
application gets all the catalogs (potentially caches them locally),
and for each package name, tracks down its renames. At the end of the
run, the most important information it should display, is which _stub
packages can now become marked incompatible with their original
package. For instance:

legacy:
CSWlibfoo / libfoo

dublin:
CSWlibfoo_dev / libfoo_dev (depends on CSWlibfoo / libfoo_stub)
CSWlibfoo1 / libfoo1 (depends on CSWlibfoo / libfoo_stub)
CSWlibfoo / libfoo_stub

kiel:
CSWlibfoo_dev / libfoo_dev
CSWlibfoo1 / libfoo1 (incompatible with CSWlibfoo / libfoo_stub; this
makes sure that when you upgrade to kiel, and have te libfoo1 package,
libfoo_stub gets removed)
CSWlibfoo / libfoo_stub (deleted)

So as you can see, we have 2 transitions to make before the package
split is complete. It doesn't make sense for a human to try to track
this. A computer program will to do it faster and more reliably.

Is anyone interested in writing it?

Maciej