libopenmpt <-> libmodplug compataibility layer
jcowgill at debian.org
Tue Jan 3 15:57:32 UTC 2017
On 01/01/17 20:11, Stephen Kitt wrote:
> On Sun, 01 Jan 2017 18:30:51 +0100, Jonas Smedegaard <jonas at jones.dk> wrote:
>> Quoting James Cowgill (2017-01-01 16:57:17)
>>> Are there any opinions about all this? My current thinking is that
>>> option 2 is too invasive to be done for stretch (if we want to do it
>>> at all), but option 1 might be possible (if it gets through NEW in
>> Deadline for getting through NEW in time for Stretch was January 4 minus
>> 10 days to settle in unstable, so that ship has already sailed.
>> I see no other option at this point in time than to try convince release
>> managers to get an exception for this. But that requires heavy
>> arguments e.g. tied to security concerns.
> I think this is a good idea, *but* I also think that the ship has already
> sailed. I'd be inclined to go for option 2 in Buster, and leave things as
> they are for Stretch. libmodplug1 has a huge popcon score, and although I'm
> well aware that doesn't mean it's actually used much, I'd rather we gave
> ourselves enough time to test things properly (which includes verifying that
> nothing in Debian relies on the features that libopenmpt's compatibility
> layer doesn't support).
> As I understand it, option 1 would be a nice half-way step, but I don't see
> the argument for it in Stretch: either libmodplug is a security concern, which
> means option 2 is the only sensible thing to do, or it isn't, which means
> option 1 doesn't bring much to the table (for Stretch).
OK - I'll bring this up again after Stretch is released.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the pkg-multimedia-maintainers