Re: Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)
Ron wrote:
> 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.
That might be a nice goal though it also affects libraries which makes
packages uninstallable which prevents unrelated RC bug fixing and
transitions...
> 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.
I suggest contacting the MIA Team or the QA Team (for bapase action on
libsndfile).
> And libarts1c2a has its own grave bug, also open since March, with no
> response whatsoever from its maintainers.
Strange, I thought the maintainers would be more responsive, lets put
them in Cc.
> 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.
Did you contact the maintainers announcing you would drop the .la file?
If so, then one could indeed argue that the maintainers should know what
is happening. Though now it looks like the maintainers are not aware and
most probably think there is an issue with libogg AFAICS.
>> 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.
While your goal is admirable, I would use a different way of achieving
it that is not so disruptive in unstable.
> 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.
Sure, if you know of packages that would get a regular upload anyway,
then they don't need to be binNMUed.
> 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 ...
I don't fully agree, but ok.
> 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.
Contacting the maintainers (and the debian-release list) would have been
helpful, I'm not sure if you did that. I would also contact the QA Team
if you know of packages that are not well maintained (so they can start
bapase for these packages) or contact the MIA Team if you know of
maintainers that seem to be missing.
Cheers
Luk
Reply to: