On Wed, Dec 13, 2006 at 08:01:58AM +0100, Andreas Barth wrote: > Actually, I think we should refuse dealing with the issue now, because > according to Don (wearing owner@bugs hat) the decision whether a bug is > RC or not is done by the release team, not the maintainer - and the > release team is just about to make a (first) decision. AFAICS the only release criteria this package potentially violates is: ] (a) Supportable ] Packages in the archive must not be so buggy or out of date we ] refuse to support them. in the sense that Debian as a whole considers the package to be unsupportable due to the complexity of its dependency on ffmpeg. Moritz has expressed significant concern that the security team won't be able to manage that support in the bug log, though according to [0] thinks an exception is appropriate: ] > I've tried it myself and it is indeed not possible to link against ] > libavcodec dynamically currently. Given that mplayer was only accepted ] > into the archive 2.5 months after the current ffmpeg snapshot was made ] > and that mplayer is an important application I do now think we can ] > ignore this RC bug for Etch as a one-time exception. In any case further ] > mplayer maintenance needs to be synchronised with Debian's libav[codec| ] > format], even if it means to not being able to upload the most recent ] > upstream version every week. If that's the case, I think that alone resolves the problem; and I think that it'd be reasonable for the ffmpeg/mplayer maintainers to resolve the problem by volunteering to handle backports of any necessary fixes for the differing ffmpeg variants to be distributed with etch. Uploading dynamically linked ffmpeg/mplayer packages to experimental for inclusion in unstable in the near future seems like a sensible thing to do too. Cheers, aj [0] http://lists.debian.org/debian-devel/2006/12/msg00322.html
Attachment:
signature.asc
Description: Digital signature