Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1

[Emilio Pozuelo Monfort <pochu@debian.org>]

On 26/01/16 17:54, Gianfranco Costamagna wrote:
> Hi Emilio!
> 
> 
>> Can send another summary with your proposed plan here? Currently libpng12-dev
>> provides libpng-dev but libpng16-dev doesn't. Are you going to switch that? Or
>> do you plan to build a libpng-dev package from src:libpng1.6?
> 
> 
> sure, the only reason that libpng-dev wasn't provided has been to avoid people building accidentally
> with libpng16 when uploading on experimental.
> 
> IIRC the plan is to upload on unstable with the Provides: libpng-dev line enabled
> (it is already there, just commented),
> and the change for the udeb file conflict (ongoing test right now).
> 
> I think libpng12-dev will stop providing the libpng-dev at the same time, but I'm not sure

Either that needs to happen, or a real libpng-dev package needs to be built.
Otherwise if we have libpng12-dev and libpng16-dev providing libpng-dev, things
won't be deterministic.

> 
>> Another thing I want to confirm before starting this transition is what Cyril
>> asked earlier today in another mail. What happens if libpng12.so and libpng16.so
>> are both loaded into a process? Does that work properly, because of versioned
>> symbols et al? E.g.
>>
>> gimp depends on libpng12-0.
>>
>> gimp also depends on libgtk2.0-0, which depends on libgdk-pixbuf2.0-0, which in
>> turn depends on libpng12-0.
>>
>> If one of gimp or libgdk-pixbufs2.0-0 get rebuilt, but the other doesn't, when
>> gimp runs then both libpng12.so and libpng16.so will get loaded. Is that supported?
> 
> 
> the problem here I think should be solved by *removing* the old libpng providing libpng-dev
> and rebuilding everything against the new libpng16.

No, that doesn't solve the problem. Rebuilding everything takes time, packages
will fail to build, and we will have processes that load both shared libraries.
That needs to work. And it needs to be tested and verified.

If that didn't work, then libpng16-16 would probably have to conflict against
libpng12-0, making this transition way harder. So please check what I asked and
let's go the other route.

Cheers,
Emilio