libopenmpt <-> libmodplug compataibility layer

[Stephen Kitt]

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 
> > time).  
> 
> 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).

Regards,

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170101/937a168c/attachment.sig>