libopenmpt <-> libmodplug compataibility layer

[James Cowgill]

Hi,

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

OK - I'll bring this up again after Stretch is released.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170103/ab299a77/attachment.sig>