Re: Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)
On Sun, Aug 09, 2009 at 06:26:32PM +0200, Luk Claes wrote:
> Ron wrote:
> > 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
Yeah, I do understand how quickly this can all snarl into horrible tangle,
but I figured we can sort that out with selective binNMUs as trouble is
apparent, and it is much harder to coordinate or predict this, since the
situation potentially changes much faster than any prior assessment can
determine the present state to be.
Any rdeps that are already RC buggy are already a spanner in that works
and they are the ones that I figured will be the most trouble anyhow.
> > 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
At least upstream seems active on that one. And the maintainer was around
to respond to #518037 in March, even if their response wasn't entirely
satisfactory and upstream themselves asked to reopen it :/ So he's not
entirely MIA ... OTOH, Erik, the upstream maintainer, does seem to be
maintaining some other packages, so perhaps we should give him a thumbs
up to hijack this one and look after it himself.
Added to the CC also. Erik, how do you feel about that ;?
> 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.
Not all of them. There was mail traded with John Ferlito, who should be
adopting libtheora, libvorbis, libspiff, vorbis-tools, uriparser, libao,
so I considered those covered, likewise the other xiph codecs I maintain
which already have their .la removed.
Previous attempts to communicate with the pkg-multimedia folks over their
use of celt while it remains an experimental codec (without even a stable
bitstream format yet) had fallen into a black hole and got no response,
so I didn't bother with them again just yet.
If people think the problem is with libogg, that should work out ok, as
they they should then contact me, or see this report, and I can talk them
through it from there, like I have with a couple of folks already.
Arguably not the optimal, or most elegant solution, but it should be a
relatively efficient way to sort the easy set, that people are paying
attention to and using, from the hard pile, which I'm keeping an eye on
and had planned to follow up on once the "early adopters" had shaken out.
> 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.
Yeah, I probably should have pinged -release earlier, though I did chat
briefly with vorlon on #d-d, when his eyebrows went up about it. I'm
still not fully aware of who will or will not be a problem with this,
in the sense of MIA et al. but I am hoping this will help answer that
for us, and that any packages that are really worth keeping will find
themselves with active maintainers again by the time we are done.