The upstream renamed, but xz is still unstable/testing only. DEPENDS on lzma-utils must instead be DEPENDS || (lzma-utils xz-utils) Having installed xz-utils, I masked lzma-utils since it'd quash xz-utils files, xz-utils -SHOULD- fully replace lzma-utils, but outdated depends produce blockers. Reproducible: Always Steps to Reproduce: 1. mask lzma-utils 2. emerge xz-utils 3. unmerge lzma-utils 4. emerge -pve world Actual Results: Calculating dependencies... done! !!! All ebuilds that could satisfy "app-arch/lzma-utils" have been masked. !!! One of the following masked packages is required to complete your request: - app-arch/lzma-utils-4.32.7 (masked by: package.mask) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "media-libs/netpbm-10.46.00" [ebuild]) (dependency required by "app-text/gocr-0.47" [ebuild]) (dependency required by "media-video/subtitleripper-0.3.4-r3" [ebuild]) (dependency required by "world" [argument]) Expected Results: Non-blocking operations, since xz-utils should provide all lzma-utils did and more. The following ebuilds need correction (according to human parse results from find /usr/portage/ -name '*.ebuild' -exec grep -H -A1 -B1 lzma-utils {} ';' | sort | tee ~/xz-lzma.txt ) app-admin/metalog/metalog-1.ebuild app-arch/libarchive/libarchive-2.6.2.ebuild app-arch/libarchive/libarchive-2.7.0-r1.ebuild app-arch/rpm2targz/rpm2targz-9.0.0.0g.ebuild app-arch/rpm2targz/rpm2targz-9.0.0.2g.ebuild app-arch/rpm2targz/rpm2targz-9.0.0.3g.ebuild app-doc/linkers-and-loaders/linkers-and-loaders-1.ebuild app-editors/le/le-1.14.2.ebuild app-office/gnucash/gnucash-2.2.9.ebuild app-office/gnucash/gnucash-2.2.9-r1.ebuild app-portage/eix/eix-0.15.4.ebuild app-portage/eix/eix-0.16.0.ebuild app-portage/eix/eix-0.16.1.ebuild app-portage/eix/eix-0.16.2.ebuild app-portage/eix/eix-0.17.0.ebuild app-text/texlive-core/texlive-core-2008-r5.ebuild dev-cpp/libmxmlplus/libmxmlplus-0.9.2_p20080323.ebuild dev-cpp/libmxmlplus/libmxmlplus-0.9.2_p20080323-r1.ebuild dev-libs/mpfr/mpfr-2.3.2.ebuild dev-libs/mpfr/mpfr-2.4.1_p1.ebuild dev-libs/mpfr/mpfr-2.4.1_p5.ebuild gnome-extra/yelp/yelp-2.24.0.ebuild gnome-extra/yelp/yelp-2.24.0-r10.ebuild gnome-extra/yelp/yelp-2.26.0.ebuild media-libs/libpng/libpng-1.2.37.ebuild media-libs/libpng/libpng-1.2.38.ebuild media-libs/netpbm/netpbm-10.44.00-r1.ebuild media-libs/netpbm/netpbm-10.46.00.ebuild net-dns/dnsmasq/dnsmasq-2.45.ebuild net-dns/dnsmasq/dnsmasq-2.46.ebuild net-dns/dnsmasq/dnsmasq-2.47.ebuild net-dns/dnsmasq/dnsmasq-2.49.ebuild net-misc/netkit-rsh/netkit-rsh-0.17-r9.ebuild rox-extra/archive/archive-2.2.ebuild sci-electronics/kicad/kicad-20090320.1666.ebuild sci-electronics/kicad/kicad-20090320.1666-r1.ebuild sys-apps/coreutils/coreutils-7.1.ebuild sys-apps/coreutils/coreutils-7.2.ebuild sys-apps/coreutils/coreutils-7.4.ebuild sys-apps/man/man-1.6f-r3.ebuild sys-apps/net-tools/net-tools-1.60_p20071202044231-r1.ebuild sys-apps/sandbox/sandbox-1.3.2.ebuild sys-apps/sandbox/sandbox-1.3.3.ebuild sys-apps/sandbox/sandbox-1.3.4.ebuild sys-apps/sandbox/sandbox-1.3.5.ebuild sys-apps/sandbox/sandbox-1.3.6.ebuild sys-apps/sandbox/sandbox-1.3.7.ebuild sys-apps/sandbox/sandbox-1.3.8.ebuild sys-apps/sandbox/sandbox-1.3.9.ebuild sys-apps/sandbox/sandbox-1.4.ebuild sys-apps/sandbox/sandbox-1.5.ebuild sys-apps/sandbox/sandbox-1.6.ebuild sys-apps/sandbox/sandbox-1.6-r1.ebuild sys-apps/sandbox/sandbox-1.6-r2.ebuild sys-apps/sandbox/sandbox-1.7.ebuild sys-apps/sandbox/sandbox-1.8.ebuild sys-apps/sandbox/sandbox-1.9.ebuild sys-apps/sandbox/sandbox-2.0.ebuild sys-apps/texinfo/texinfo-4.12.ebuild sys-apps/texinfo/texinfo-4.13.ebuild sys-devel/gdb/gdb-6.8.50.20090302.8.11.ebuild sys-devel/gdb/gdb-6.8-r1.ebuild sys-devel/gdb/gdb-6.8-r2.ebuild sys-devel/libtool/libtool-2.2.6a.ebuild sys-devel/m4/m4-1.4.12.ebuild sys-devel/m4/m4-1.4.13.ebuild sys-kernel/linux-headers/linux-headers-2.6.27-r2.ebuild sys-kernel/linux-headers/linux-headers-2.6.28-r1.ebuild sys-kernel/linux-headers/linux-headers-2.6.29.ebuild sys-kernel/linux-headers/linux-headers-2.6.30-r1.ebuild sys-libs/gpm/gpm-1.20.5.ebuild sys-libs/gpm/gpm-1.20.6.ebuild
More formally: DEPENDS should use || (app-arch/lzma-utils app-arch/zx-utils)
Assigning to lzma-utils maintainer for now, feel free to re-assign or give me further instructions including breaking this up into 26 bugs, one for each package and marking each bug as blocking this one
Maybe we should instead have a more complicated virtual package. Something like virutal/archive with use flags for gz bz2 lzma xy cpio tar zip unzip rar unrar 7z . A package could then depend on virtual/archive [zip] and expect 'zip' or a wrapper invokable the same way within the standard system paths. Unfortunately that would require something more complicated than I know we currently have, packages providing virtual targets not by name, but by flag. As a work-around something like virtual/command-tar , virtual/command-unzip etc might be a good idea. Then there would be a new policy for requiring/providing program 'interfaces' and any package or combination of packages that sadisfy those could transparently provide the interface, while any packages that merely depend on a 'standard' program being there would not need to be re-written every time a new provider is introduced.
this will not be handled by a virtual. update the packages in question to use an OR dep until a stable xz-utils release happens. then we'll drop lzma-utils completely.
Packages which require liblzmadec.so (which is not part of xz-utils, but is supplied by lzma-utils) will need extensive patching. So far the only such package I've run across is gnome-extra/yelp.
I am highly interested to resolve this bug, since I do not want to release the eix package in a format (.lzma) which is practically considered obsolete by upstream. I run xz-utils as a replacement for lzma-utils since months on all my systems without any problems. Anyway, I do not use gnome: In reply to comment #5: This is a serious obstacle for a soon replacement, of course. I guess gnome upstream will have to fix this anyway some day. Until then, gentoo might easily support both: It would be easy to make a new lzma-libs package (or to add a useflag to lzma-utils) which only installs the libraries of lzma-utils but not the binaries/man pages; essentially the ebuild would just have to remove the stuff in /usr/bin and /usr/share/man/man1 before the installation - the rest (header files and libraries and of course the stuff in /usr/share/doc) has no collision with xz-utils, so that yelp would need no patches when it just has the corresponding dependency.
*** Bug 282684 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Until then, gentoo might easily support both: It would be easy to make a new > lzma-libs package (or to add a useflag to lzma-utils) which only installs > the libraries of lzma-utils but not the binaries/man pages; Sounds like a good idea. I masked lzma-utils and portage showed me kde-base/ark depends on app-arch/libarchive which links against liblzmadec.
libarchive is already fixed upstream. see Bug 284233. if nothing else is using liblzmadec, then there isnt much point in supporting it
playonlinux is still depending on lzma only
this is a tracker. it isnt for people to post random packages.
(In reply to comment #10) > playonlinux is still depending on lzma only > No. ssuominen@unique ~/gentoo-x86/app-emulation/playonlinux $ grep lzma * ssuominen@unique ~/gentoo-x86/app-emulation/playonlinux $
(In reply to comment #11) > this is a tracker. it isnt for people to post random packages. > Everything except gnome-extra/yelp fixed.
gnome done. However please note that using man will just result in big failure since it doesn't take into account that xz-utils does not install un/lzma binary anymore but un/xz, symlinking seems to work for me.
And tree is fixed. Thanks guys.
(In reply to comment #6) > xz-utils does not install un/lzma binary anymore but un/xz, > symlinking seems to work for me. I do not understand: All versions of the ebuild I tried installed such symlinks for un/lzma.
(In reply to comment #16) > > xz-utils does not install un/lzma binary anymore but un/xz, > > symlinking seems to work for me. > I do not understand: All versions of the ebuild I tried installed such > symlinks for un/lzma. lzma-utils -ebuild had only RDEPEND set with blockers (missing DEPEND) and somehow he got them installed at the same time in a way that uninstalling lzma-utils took away the symlinks... Should be fixed by... http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-arch/lzma-utils/lzma-utils-4.32.7.ebuild?r1=1.7&r2=1.8
*** Bug 284486 has been marked as a duplicate of this bug. ***
