Gianfranco Costamagna <costamagnagianfranco@yahoo.it> (2016-01-26): > >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) This is not a plan… You don't get to ignore partial upgrades. Scheduling binNMUs to build all packages against a newer libpng doesn't mean that testing, or end users, are going to receive all rebuilt packages in lockstep. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature