Now we are like that: libarchive 2.7.0 depends on lzma-utils and links to liblzmadec.so libarchive 2.7.1 depends on xz-utils and links to liblzma.so xz-utils and lzma-utils block each other. What happens when upgrading: xz-utils gets built, installed while lzma-utils is removed. libarchive gets broken; bsdtar doesn't work any more -> can't do anything. I poked Zac about this but it seems portage can't do much about it. The simplest solution seems to do an old school preserve-libs for liblzmadec in xz-utils, alike the preserve_old_lib function from eutils. Opinions?
Same by me. Command "emerge -fuDNv world" end with: [blocks B ] app-arch/lzma-utils ("app-arch/lzma-utils" is blocking app-arch/xz-utils-4.999.9_beta) [blocks B ] app-arch/xz-utils ("app-arch/xz-utils" is blocking app-arch/lzma-utils-4.32.7)
cc'ing portage people. IMHO it shouldn't blindly unmerge packages still referenced by system packages.
(In reply to comment #2) > cc'ing portage people. IMHO it shouldn't blindly unmerge packages still > referenced by system packages. We can fix that, using the --depclean code which does the same thing (currently in trunk/2.2_rc only). However, that will make the blocker unsolvable since we won't be able to uninstall app-arch/lzma-utils. So the simplest short-term solution is to make the xz-utils do manual preservation of the required library.
(In reply to comment #3) > (In reply to comment #2) > > cc'ing portage people. IMHO it shouldn't blindly unmerge packages still > > referenced by system packages. > > We can fix that, using the --depclean code which does the same thing (currently > in trunk/2.2_rc only). However, that will make the blocker unsolvable since we > won't be able to uninstall app-arch/lzma-utils. So the simplest short-term > solution is to make the xz-utils do manual preservation of the required > library. > Hi guys, How can I do that? I'm on x86 but lzma-utils and xz-utils are blocking each other as well. Also, I would like to understand why this change (lzma-utils -> xz-utils) happened. Thank you.
(In reply to comment #4) > How can I do that? I'm on x86 but lzma-utils and xz-utils are blocking each > other as well. Also, I would like to understand why this change (lzma-utils -> > xz-utils) happened. If the blocker doesn't solve automatically then it means that either lzma-utils is in your world file, or it got pulled in by some other package that needs to have its dependencies updated to pull in xz-utils. Acually, this can also happen with stable portage (2.1.6.x) even if the dependencies have been updated to pull in || ( xz-utils lzma-utils ). It's handled automatically in >=portage-2.2_rc34 thanks to patches from bug 264434 and bug 275796. If you're using stable portage (2.1.6.x), you'll have to manually uninstall lzma-utils. Don't forget to make backups of /usr/lib/liblzmadec.* though, if you're running FreeBSD.
(In reply to comment #5) > (In reply to comment #4) > > How can I do that? I'm on x86 but lzma-utils and xz-utils are blocking each > > other as well. Also, I would like to understand why this change (lzma-utils -> > > xz-utils) happened. > > If the blocker doesn't solve automatically then it means that either lzma-utils > is in your world file, or it got pulled in by some other package that needs to > have its dependencies updated to pull in xz-utils. I don't have lzma-utils in my world file. That's what I see when I try a "emerge --update --deep --newuse world -pv": * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('installed', '/', 'app-arch/lzma-utils-4.32.7', 'nomerge') pulled in by app-arch/lzma-utils required by ('ebuild', '/', 'sys-devel/libtool-2.2.6a', 'merge') app-arch/lzma-utils required by ('ebuild', '/', 'media-libs/libpng-1.2.38', 'merge') ('ebuild', '/', 'app-arch/xz-utils-4.999.9_beta', 'merge') pulled in by app-arch/xz-utils required by ('ebuild', '/', 'app-arch/libarchive-2.7.1', 'merge') I'm not running BSD, but I can see that xz-utils is masked on x86, so that's why I asked why lzma-utils is being replaced... > Acually, this can also happen with stable portage (2.1.6.x) even if the > dependencies have been updated to pull in || ( xz-utils lzma-utils ). It's > handled automatically in >=portage-2.2_rc34 thanks to patches from bug 264434 > and bug 275796. If you're using stable portage (2.1.6.x), you'll have to > manually uninstall lzma-utils. Don't forget to make backups of > /usr/lib/liblzmadec.* though, if you're running FreeBSD. Yeah, I'm using a stable portage. I will uninstall lzma-utils as soon as I understand why this replacement is taking place :-). Thank you, Zac!
(In reply to comment #6) > I don't have lzma-utils in my world file. That's what I see when I try a > "emerge --update --deep --newuse world -pv": > > * Error: The above package list contains packages which cannot be > * installed at the same time on the same system. Completely unrelated to this bug. First sentences on xz-utils homepage explains it; "XZ Utils are the successor to LZMA Utils.". emerge -C lzma-utils, and enjoy.
*** Bug 293390 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Yeah, I'm using a stable portage. I will uninstall lzma-utils as soon as I > understand why this replacement is taking place :-). > > Thank you, Zac! > Because lzma-utils is deprecated in favor of xz-utils. Don't know why they changed the name, but that's it. Indeed, lzma-utils are not being developed anymore. See: http://tukaani.org/xz/ Cheers.
(In reply to comment #9) Uh, sorry people. I was reading two bug reports and I got confused with the dates. You had already answered that. Is this bug still valid, by the way?
@bsd folk: Any reason this can't be closed? Issue's well past (been a year)...
(In reply to comment #11) > @bsd folk: > > Any reason this can't be closed? Issue's well past (been a year)... > this one can probably be closed as long as bug #286714 remains open; portage can still remove core packages under one's feet without prior notice afaik
(In reply to comment #12) > (In reply to comment #11) > > @bsd folk: > > > > Any reason this can't be closed? Issue's well past (been a year)... > > > > this one can probably be closed as long as bug #286714 remains open; portage > can still remove core packages under one's feet without prior notice afaik ok then: https://bugs.gentoo.org/show_bug.cgi?id=286714#c11
