Gianfranco Costamagna <[email protected]> (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.
signature.asc
Description: Digital signature
