Re: Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)

[Ron <ronl@internode.on.net>]

On Sun, Aug 09, 2009 at 01:04:36PM +0200, Luk Claes wrote:
> Hmm, you do know that it's your job to hand that list (including all the
> reverse deps of reverse deps ...) to the release team including the
> necessary dep waits so we don't have to reschedule them till all succeeded?

Well, to be frankly honest, I don't actually _want_ you guys to blindly
schedule blanket binNMUs for the lot of these.  I'd much rather that it
shook out all the packages that were as neglected as this was when I had
adopting it thrust upon me unexpectedly, and that the relevant maintainers
either take some action themselves to remedy things, or that it becomes
clear that they are also abandoned and other project members will be free
to act on that as they may care to.

As a first round, I'd really prefer that the only binNMUs come as requests
from the maintainers of those packages, who _know_ they are in good order,
and don't care to immediately remove their own .la files, and that a simple
rebuild will in fact suffice for them for now.

If we take a cursory look at this lot, surprise, surprise, we see that
libsndfile already has its own RC bug, open since March, and a bug
requesting that its own .la be fixed or removed, since it's broken and
dragging in unneeded dependencies.

And libarts1c2a has its own grave bug, also open since March, with no
response whatsoever from its maintainers.

So no, I wouldn't recommend that those packages be binNMUed, I'd suggest
their maintainers either fix them, be replaced by maintainers that will,
or orphan them honourably and drop them in the QA pile.  YMMV, and that's
your call with an RM hat on.


> There is a reason we advise to only remove a .la file once it's (almost)
> not used anymore...

Actually, vorlon suggested an even better way, that I wasn't aware of
when I initially decided this, and that I probably will use for the
next one I drop that has a lot of rdeps with maintainers that it would
be impossible to coordinate a transition with.  But as hindsight on
this particular case is clarifying, it seems like this has quite a good
chance of being a Good Thing for the quality and preparedness of squeeze
for release, iff we don't just blindly mask the problems it identifies
with a series of blanket, quick-fix, binNMUs.

But that bit's your job to decide.  My original plan was to look at what
stragglers might remain after the package maintainers had their own chance
to do new uploads.  I know that at least all of the former pkg-xiph lot
are currently in the process of being adopted by new maintainers.
It seemed silly to race against them with binNMUs when all indications
were that they'd be uploading new packages very shortly too.

Sorry if I ham-fisted things in a way that made your job harder, but I
decided this with good faith intentions for improving the quality of
the squeeze release, and so far I'm not really seeing any signs that
it is failing at that, despite some temporary pain in unstable for a
few things, and perhaps some now-scheduled binNMUs that should in fact
not be binNMUed at all ...

If you have other suggestions, I'll be happy to take them on-board for
the next time I have to decide things that affect your team's work.

Cheers,
Ron