Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1
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
>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.
I don't think anybody will keep the old 12 around, specially when ~10 packages needs porting.
My plan (that is *my* plan), is to switch everything to the new one, and do the rebuilds
accordingly (dep-wait or similar, not sure how to manage the gdk dependency problem)
>Assuming that works fine, this is looking good and should be ready to start soon.
in 2-3 days most of the NMUs will reach unstable, and in 10 dayes the remaining NMUs will go too.
(assuming we don't speed them up :) )
BTW you might want to start in a future reply from this message
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#691
that has a more complete point of view of the transition
seems that only RC buggy packages are left to, but there is no way to fix them if we can't even build with the old
libpng (even to test if they would build fine or not).
cheers,
Gianfranco
Reply to: