dev-libs/libxml2 is required to build libarchive (used as part of its configure script) and is linked to the library so its also needed in runtime; # ldd /lib64/libarchive.so linux-vdso.so.1 => (0x00007fff5bdff000) libacl.so.1 => /lib/libacl.so.1 (0x00007f712d554000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f712d331000) libbz2.so.1 => /lib/libbz2.so.1 (0x00007f712d120000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00007f712cdcd000) libz.so.1 => /lib/libz.so.1 (0x00007f712cbb6000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f712c82f000) libc.so.6 => /lib/libc.so.6 (0x00007f712c4c3000) libattr.so.1 => /lib/libattr.so.1 (0x00007f712c2be000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f712c0a0000) libdl.so.2 => /lib/libdl.so.2 (0x00007f712be9c000) libm.so.6 => /lib/libm.so.6 (0x00007f712bc1a000) /lib64/ld-linux-x86-64.so.2 (0x00007f712d9be000)
Hate that dep; it's controlled via xar, not a hugely used format. Will fix the dep, but would be curious on any thoughts on making xar configurable...
fixed/pushed.
You can't set automagic like this: || ( dev-libs/libxml2 dev-libs/expat ) If user has both of dev-libs/libxml2 and dev-libs/expat installed, he installs libarchive which will link to it and then libxml2 get --depcleaned since expat will satisfy the depend -> libarchive will break.
(In reply to comment #3) > You can't set automagic like this: > || ( dev-libs/libxml2 dev-libs/expat ) Correction of terms; automagic is when the dep is completely outside of the PM's knowledge- PM knows of the deps, even if it's not specifically annotated that it is a binding choice. In this case, the manager *could* actually lock the dep if it wanted (despite your claim I might add), just none of them choose to. Few things, bearing in mind I understand this issue pretty well: 1) it's not banned. Check pms, check devmanual. 2) Were it to have been banned, it would've crossed my desk as a council member. It hasn't. 3) everytime someone pushes for a bannination of it (rather than modifying depset syntax to remove the issue in it's entirety via some form of locked annotation) it gets smacked down because bluntly, such a stance is naive, even if there is some technical correctness to it. 4) What particularly pisses me off; do not go around telling people things are disallowed when they're not. Especially when past attempts to push the disallowing were slapped down. You want something disallowed, get it documented (including approved) instead of just telling people what amounts to conflicting commandments, especially if you're doing so as a member of QA (which the cc'ing indicates you were trying to do). I'm well aware of the issues with ||( ), but in this case I decided it was better than the alternative of forcing flags for it. Argue an alternative if you'd like, but skip the "it's not allowed (but it is, if frowned on)". If you'd like to reopen the bug, sort the docs, or give an alternative. As said, I don't particularly like the solution there, but this false disallowed crap annoys me more.
Also, kindly skip the hand slapping for not revbumping it for the change. Fully admit I missed on that one...
We already have documentation for this: http://www.gentoo.org/proj/en/qa/automagic.xml "To simplify, when an automagic dependency is not stated as mandatory in an ebuild, but rather has a flag that just adds or remove the dependencies on a given package, if this package is present in the system building the software with automagic dependencies, but then it's removed, the software will break," And given this package is mandatory for functional ~*-fbsd systems, this should get fix asap before any user needs to recover his system.
IUSE="+xml" xml? ( dev-libs/libxml2 ) !xml? ( dev-libs/expat ) $(use_enable xml) $(use_enable !xml expat) And a patch fixing the automagic. This is more or less covered also in end-quiz, 2. which you should have answered properly to pass it.
This would be bug 284458 all over again.
(In reply to comment #6) > We already have documentation for this: > > http://www.gentoo.org/proj/en/qa/automagic.xml > > "To simplify, when an automagic dependency is not stated as mandatory in an > ebuild, but rather has a flag that just adds or remove the dependencies on a > given package, if this package is present in the system building the software > with automagic dependencies, but then it's removed, the software will break," And as I said, it's not automagic. Automagic by its definition is allowing the configure to link against whatever the hell it wants without any representation in the metadata. The representation is there, it's a hard dep, not an optional. Your terms are wrong. What you're doing here is trying to state that automatically all usage of '|| ( )' for linkage deps are banned- and I'm pushing back hard because it's come up before and it's lost out each time. If you want to enforce a ban on all usage of "|| ( )" for build linkage, you need to go to dev ml and propose it, get it approved, and update the official docs (devmanual and pms in particular, rather than a discussion of why configure should not be assumed to mirror use conditionals intentions). Specifically since you're trying to push to contravene developer will thus far, you need to go get some feedback instead of just trying to enforce it silently. There in is the rub; get your rules sorted (and in this case, actually fully agreed to) before you try enforcing it as writ law instead of "preferable". > And given this package is mandatory for functional ~*-fbsd systems, this should > get fix asap before any user needs to recover his system. Rewritten to IUSE. I blatantly hate that usage in this case, but the system arg was good enough for this package. > This is more or less covered also in end-quiz, 2. which you should have > answered properly to pass it. Play nice. Or go do a cvs annotate on the quizes and look for 'ferringb', or check into FEATURES=verify-rdepend (which someone should resurrect).
