Actualy the ebuild shows a fixed dependency on app-arch/lzma-utils but this scenario can leads to blocks if the end-user have installed app-arch/xz-utils as shown below: Calculating dependencies ....... done! [ebuild N ] app-arch/lzma-utils-4.32.7 USE="-nocxx" 0 kB [0] [uninstall ] app-arch/xz-utils-4.999.9_beta-r1 USE="nls threads -static-libs" [1] [blocks b ] app-arch/lzma-utils ("app-arch/lzma-utils" is blocking app-arch/xz-utils-4.999.9_beta-r1) [blocks b ] app-arch/xz-utils ("app-arch/xz-utils" is blocking app-arch/lzma-utils-4.32.7) [ebuild R ] app-portage/eix-0.17.0 USE="nls -deprecated -doc -sqlite -tools" 0 kB I have tested eix 0.17.0 with app-arch/xz-utils and it unpack correctly the lz archive; attached there is an ebuild patch that fixes the issue. Hope to be useful. Mauro Toffanin
Created attachment 208127 [details, diff] eix-0.17.0-r1.ebuild.patch
Sorry, you shouldn't be mixing stable and ~arch trees. This is not supported. >=eix-0.18 works fine with lzma or xz, use that instead.
Created attachment 208141 [details, diff] eix-0.18.2-r1.ebuild.patch
(In reply to comment #2) > Sorry, you shouldn't be mixing stable and ~arch trees. This is not supported. > >=eix-0.18 works fine with lzma or xz, use that instead. Sorry, but here i'm not mixing anything, the stable release of eix is 0.17.x and not 0.18.x, so your suggestion is a little insane; however eix-0.18.2 suffers the same issue, I need lzma-utils (i know it's deprecated) installed, but your ebuild whant to pull in xz-utils so I need to remove xz-utils and manually reinstall lzma-utils; on other machines the stable version of eix just does the same oppisite pulling in lzma-utils where I want xz-utils, why I need to do all these workarounds when the proper fix is the usage of: "|| ( app-arch/xz-utils app-arch/lzma-utils )" as done by all other similiar ebuilds in portage tree? Calculating dependencies ... done! [ebuild N ] app-arch/xz-utils-4.999.9_beta-r1 USE="nls threads -static-libs" 0 kB [1] [uninstall ] app-arch/lzma-utils-4.32.7 USE="-nocxx" [0] [blocks b ] app-arch/lzma-utils ("app-arch/lzma-utils" is blocking app-arch/xz-utils-4.999.9_beta-r1) [blocks b ] app-arch/xz-utils ("app-arch/xz-utils" is blocking app-arch/lzma-utils-4.32.7) [ebuild U ] app-portage/eix-0.18.2 [0.17.0-r1] USE="bzip2%* nls -deprecated -doc -sqlite -tools" 483 kB [2=>0] please fix it, thank you
see comment #4
(In reply to comment #4) > Sorry, but here i'm not mixing anything, the stable release of eix > is 0.17.x and this works with the stable lzma-utils but not with the testing xz-utils. So unless you mix stable and unstable, there is no problem. > so your suggestion is a little insane Actually it is your proposal which is a little insane: You say you want to keep lzma-utils, but simultaneously you complain that with eix-0.17 you cannot upgrade to xz-utils. Make up your mind! It is not the eix ebuild's fault that xz-utils and lzma-utils cannot be installed together. Once you have decided whether you want to use the (currently stable but deprecated) lzma-utils or the unstable xz-utils you can emerge the corresponding eix-version - naturally, the stable for lzma-utils or the unstable for xz-utils. However, sooner or later you will have to change to xz-utils: eix-0.18.* does not work with lzma-utils, since I will not release the tarball in a deprecated format. In particular, your patch for eix-0.18.2 would break things for users, since lzma-utils cannot be used to unpack the eix-0.18.2 tarball. The best thing would be to cure the cause and not the symptom: Fix the application for which you need the obsolete lzma-utils installed and then upgrade to xz-utils and eix-0.18.* (both currently in the testing branch, of course).
(In reply to comment #4) > to do all these workarounds when the proper fix is the usage of: "|| ( > app-arch/xz-utils app-arch/lzma-utils )" as done by all other similiar ebuilds > in portage tree? Because lzma-utils cannot unpack a .tar.xz archive. So, this || block will not work for eix-0.18*. It will work for the stable eix, but I'm not going to change the stable ebuild. Again, closing as invalid.
