[csw-maintainers] A systematic approach to package renames

[Ben Walton]

Excerpts from Maciej (Matchek) Bliziński's message of Sun Jan 15 08:08:04 -0500 2012:

> So far, each maintainer tracked in their heads the states of their
> packages. It's easy when you maintain 5 packages, but quickly gets
> confusing as the number of packages increases. I think we'd be

Yes, this does get to be a lot of state to maintain.

> better off with a systematic approach. I already hacked some code to
> analyze the transitions, but it's nothing really useful yet. I think
> that Ben's integration scripts already have a lot of relevant logic,
> e.g.  detecting both catalogname and pkgname changes.

There is a lot of this logic encapsulated.  It would need to be
factored a bit to make it a generally useful standalone library, but
that shouldn't be too bad, I don't think.

> I would imagine a tool that would retrieve catalog metadata, analyze
> the state and detect errors / make suggestions. For example:
> 
> - Opportunity: Package foo_stub present in dublin, so it could be
> transitioned to the next stage in the next release

Yes, this would be good to catch.  (Skipping the generation of stub
packages automatically once they're released would be cool too but
that's a different topic.)

> - Error: Package foo present in dublin, but there is no foo nor
> foo_stub in unstable; premature package removal

This could also be a normal package drop.  Eg: apache1.  I would say
that this is a warning at most.  (But you're talking about generating
suggestions anyway, so that an equivalent.)

> - Unnecessary stub: package foo_stub present in unstable, but there
> is no foo in dublin

This _could_ happen legitimately if a package is reshaped while it's
in unstable.  The likelihood of this increases with the length of time
between cutting stable catalogs.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302