!!! existing preserved libs: >>> package: media-libs/libpng-1.6.1 * - /usr/lib64/libpng15.so.15 * - /usr/lib64/libpng15.so.15.15.0 * used by /usr/lib64/libreoffice/program/oosplash (app-office/libreoffice-bin-3.6.4.3) # ldd /usr/lib64/libreoffice/program/oosplash | grep libpng libpng15.so.15 => /usr/lib64/libpng15.so.15 It seems as if the ebuild should depend on a libpng 1.5 slot.
right, same as bug 464914, since this is gentoo rolled binary package, rerolling one based on libpng 1.6 is the solution here meanwhile I've fixed the dependency to =media-libs/libpng-1.5* to allow both libpng-1.5.15:0 and libpng-1.5.15-r15:1.5 so it'll work for both, stable and ~arch users leaving this bug open as an enhancement request for rerolling the package based on 1.6
Not going to happen. We are providing as a general rule libreoffice-bin for a fully stable installation. Everything else would require way too much work and cpu time. (And my flat is already overheated.)
(In reply to comment #2) > Not going to happen. We are providing as a general rule libreoffice-bin for > a fully stable installation. Everything else would require way too much work > and cpu time. (And my flat is already overheated.) And what happens when we stabilize >=media-libs/libpng-1.6, but leave out SLOT="1.5" in purpose to make the Portage output more clear for stable users? Do you want libreoffice-bin to get reverted back to ~arch then?
(In reply to comment #3) > (In reply to comment #2) > > Not going to happen. We are providing as a general rule libreoffice-bin for > > a fully stable installation. Everything else would require way too much work > > and cpu time. (And my flat is already overheated.) > > And what happens when we stabilize >=media-libs/libpng-1.6, > but leave out SLOT="1.5" in purpose to make the Portage output more clear > for stable users? > Do you want libreoffice-bin to get reverted back to ~arch then? We spin a new version then, and maybe remove the old one. (Which is why I'd like to have some advance warning of the stabilization, but luckily due to preserved-libs this is not so extremly urgent anymore.) For exactly this reason many of the dependencies in libreoffice-bin look like =media-libs/libpng-1.5* or similar now already. In the future, I'll depend on exact subslot.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Not going to happen. We are providing as a general rule libreoffice-bin for > > > a fully stable installation. Everything else would require way too much work > > > and cpu time. (And my flat is already overheated.) > > > > And what happens when we stabilize >=media-libs/libpng-1.6, > > but leave out SLOT="1.5" in purpose to make the Portage output more clear > > for stable users? > > Do you want libreoffice-bin to get reverted back to ~arch then? > > We spin a new version then, and maybe remove the old one. (Which is why I'd > like to have some advance warning of the stabilization, but luckily due to > preserved-libs this is not so extremly urgent anymore.) > > For exactly this reason many of the dependencies in libreoffice-bin look > like =media-libs/libpng-1.5* or similar now already. In the future, I'll > depend on exact subslot. I'll try to remember let you know before CCing arch's on the future libpng stabilization request. And you are right, there is preserve_old_lib in place for Portage 2.1 users, so it won't immediately break up either.
*** Bug 469714 has been marked as a duplicate of this bug. ***
So, if I understand correctly, currently the only way - as libpng does not use preserve_old_lib - is to downgrade to libpng-1.5, copy the binaries, upgrade to libpng-1.6, then copy those .15 binaries back that are required? Because currently libreoffice-bin appears to be broken, because soffice.bin links against libpng-1.6, but oosplash links against libpng-1.5. I have a feeling that this should not be so.
nothing in libreoffice is linked to 1.6 if some tool says it is so then the tool is broken. Libreoffice-bin is built only against the stable system which was nowhere near such libpng version. The ebuild has even hardcoded dependency over libpng-1.5, what would you like more.
OK, clear enough. ldd must be broken ;-) markus@slim:~$ ldd /usr/lib64/libreoffice/program/soffice.bin | grep png libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007ffd83654000) markus@slim:~$ ldd /usr/lib64/libreoffice/program/oosplash | grep png libpng15.so.15 => /usr/lib64/libpng15.so.15 (0x00007f97452a3000) (after copying the 1.5 binaries to /usr/lib, before that it read "not found") I'm far from understanding the intricacies of all this. But should not the hardcoded dependency over libpng-1.5 prevent libpng-1.5 from being removed?
ah, yes, I forgot: obviously I'm on ~amd64. relax.
