Should be trivial recompile, may bring up missing #include <string.h> like for memset(), memcpy() !!! existing preserved libs: >>> package: media-libs/libpng-1.6.1 * - /usr/lib64/libpng15.so.15 * - /usr/lib64/libpng15.so.15.15.0 * used by /opt/icedtea-bin-7.2.3.8/jre/lib/amd64/libsplashscreen.so (dev-java/icedtea-bin-7.2.3.8) Use emerge @preserved-rebuild to rebuild packages using these libraries
+ 09 Apr 2013; Samuli Suominen <ssuominen@gentoo.org> + icedtea-bin-6.1.12.2.ebuild, icedtea-bin-6.1.12.4.ebuild, + icedtea-bin-7.2.3.6.ebuild, icedtea-bin-7.2.3.8.ebuild: + Avoid pulling in libpng16 for now wrt #464914 Changed from >=media-libs/libpng-1.5 to =media-libs/libpng-1.5* since I've added binary-only SLOT="1.5" for libpng, and only for this package -- at least I don't know any other binary-only pkgs using libpng 1.5 yet
(In reply to comment #1) > + 09 Apr 2013; Samuli Suominen <ssuominen@gentoo.org> > + icedtea-bin-6.1.12.2.ebuild, icedtea-bin-6.1.12.4.ebuild, > + icedtea-bin-7.2.3.6.ebuild, icedtea-bin-7.2.3.8.ebuild: > + Avoid pulling in libpng16 for now wrt #464914 > > Changed from > > >=media-libs/libpng-1.5 > > to > > =media-libs/libpng-1.5* > > since I've added binary-only SLOT="1.5" for libpng, and only for this > package -- at least I don't know any other binary-only pkgs using libpng 1.5 > yet Problem is that quite a few packages depend on libpng being in SLOT 0. So, in ~amd64 at least, attempting to install the SLOT="1.5" version will lead to portage attempting to install both libpng-1.5.15 and libpng-1.5.15-r15 at the same time which leads to a big block. IMO, it would be better to remove the SLOT from -r15 and have the binary package just depend on that particular version (r15) or something similar.
(In reply to comment #2) > (In reply to comment #1) > > + 09 Apr 2013; Samuli Suominen <ssuominen@gentoo.org> > > + icedtea-bin-6.1.12.2.ebuild, icedtea-bin-6.1.12.4.ebuild, > > + icedtea-bin-7.2.3.6.ebuild, icedtea-bin-7.2.3.8.ebuild: > > + Avoid pulling in libpng16 for now wrt #464914 > > > > Changed from > > > > >=media-libs/libpng-1.5 > > > > to > > > > =media-libs/libpng-1.5* > > > > since I've added binary-only SLOT="1.5" for libpng, and only for this > > package -- at least I don't know any other binary-only pkgs using libpng 1.5 > > yet > > Problem is that quite a few packages depend on libpng being in SLOT 0. So, > in ~amd64 at least, attempting to install the SLOT="1.5" version will lead > to portage attempting to install both libpng-1.5.15 and libpng-1.5.15-r15 at > the same time which leads to a big block. > > IMO, it would be better to remove the SLOT from -r15 and have the binary > package just depend on that particular version (r15) or something similar. no. libpng-1.5.15-r15 can be co-installed together with libpng-1.6.1 just fine. there is no dependency conflict unless user makes mistake with package.keywords, or package.mask for example. the ebuilds are fine in same stabilization levels, arch or ~arch. if you need futher help, please use gentoo forums or IRC instead of bugzilla this bug is about adding libpng 1.6 support to icedtea-bin, and that's it
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > + 09 Apr 2013; Samuli Suominen <ssuominen@gentoo.org> > > > + icedtea-bin-6.1.12.2.ebuild, icedtea-bin-6.1.12.4.ebuild, > > > + icedtea-bin-7.2.3.6.ebuild, icedtea-bin-7.2.3.8.ebuild: > > > + Avoid pulling in libpng16 for now wrt #464914 > > > > > > Changed from > > > > > > >=media-libs/libpng-1.5 > > > > > > to > > > > > > =media-libs/libpng-1.5* > > > > > > since I've added binary-only SLOT="1.5" for libpng, and only for this > > > package -- at least I don't know any other binary-only pkgs using libpng 1.5 > > > yet > > > > Problem is that quite a few packages depend on libpng being in SLOT 0. So, > > in ~amd64 at least, attempting to install the SLOT="1.5" version will lead > > to portage attempting to install both libpng-1.5.15 and libpng-1.5.15-r15 at > > the same time which leads to a big block. > > > > IMO, it would be better to remove the SLOT from -r15 and have the binary > > package just depend on that particular version (r15) or something similar. > > no. libpng-1.5.15-r15 can be co-installed together with libpng-1.6.1 just > fine. there is no dependency conflict unless user makes mistake with > package.keywords, or package.mask for example. the ebuilds are fine in same > stabilization levels, arch or ~arch. > if you need futher help, please use gentoo forums or IRC instead of bugzilla > this bug is about adding libpng 1.6 support to icedtea-bin, and that's it I'll just open a separate bug about the issue since it's tangent to this issue.
(In reply to comment #4) > I'll just open a separate bug about the issue since it's tangent to this > issue. You didn't mention any bugs at least here. The SLOTs are all as designed and proven to be working well from earlier libpng (and other) upgrades. # emerge -pv icedtea-bin libpng:0 libpng:1.5 [ebuild R ] media-libs/libpng-1.6.1:0/16 USE="apng (-neon) -static-libs" 0 kB [ebuild R ] dev-java/icedtea-bin-7.2.3.8:7 USE="X alsa -cjk -cups -doc -examples -nsplugin -source" 0 kB [ebuild R ] media-libs/libpng-1.5.15-r15:1.5 USE="apng (-neon)" 0 kB That's why I suggested using forums and/or IRC since you seem to need more of an help of understanding the portage output than anything else.
*icedtea-bin-7.2.3.9 (29 Apr 2013) 29 Apr 2013; Vlastimil Babka <caster@gentoo.org> +icedtea-bin-7.2.3.9.ebuild: Version bump, security bug #466822. Installs libpng-1.5 or libpng-1.6 file depending on what is detected, bug #464914.
