I think this would be most visible in the case of binary packages, but its as visible inside a system as there (just harder to think of). say the virtual ssl wrapper thingie for an example, it has RDEPEND="|| ( gnutls openssl )" DEPEND="${RDEPEND} java-config" (just to have something) src_compile () { want gnutls foo or openssl (because thats how ./configure prefers it..) } Now, when this is built and installed, which library will be depended on for a GRP set? gnutls or openssl? if you build it on a clean system, where gnutls is avaiable, it will link to that. Now, say I install this on my other system, where I already have openssl.. Will it demand gnutls, or just ignore that and leave me with an inconsistent system? If I have gnutls, install this, install openssl, can I then remove gnutls without portage reacting to a change in the dependencies? Since the compile time depend is still satisfied.... This could probably change with a way of redefining such dependencies once a package is built, by "locking" the installed case (and binary) to only one of said dependencies. (satisfied one, or first one. ) (changing RDEPEND, that is...) Reproducible: Always Steps to Reproduce: 1. 2. 3.
I am not sure if anyone has looked at this in regard to head, so I will bump the severity a bit to get attention. It definately should be fixed, especially since there should be better binpkg handling in head to ease the use of binaries across systems.
Yes, this will be addressed in the next version. When packages are built (whether for installing or binary packaging) *DEPEND will be folded down to exactly what portage chose as the deps. That is, all USE flag information and optional dependencies as listed in this bug will be removed.
Thats great. Can we perhaps make so that an original copy of the ebuild is installed as well? Since currently /var/db/pkg/*/*/*ebuild is the same as /usr/portage, this makes for good "backup" if a package is removed/changed radically and somone wants to hold a "backwards" compatible system in. This isn't really necessary and can probably be considered "bloat" but it may still be a nice thing.
Err... eh? We already hold onto the ebuild. Doesn't really do much without $FILESDIR either, nor the eclasses, but the env saving sort of addresses that.
Hmm, good points. Disregard my comment then.
pong - is this implemented in 2.1?
(In reply to comment #6) > pong - is this implemented in 2.1? No it's not been implemented as of yet. Some || ( ) style deps are proving to be problematic.
*** Bug 141226 has been marked as a duplicate of this bug. ***
Do we have a clear technical idea here? Sounds like some of the cases are handled currently by subslots, some are not. But the bug seems vague, lacking a suggested solution.
For ambiguous cases like || ( gnutls openssl ), can we assume that it will choose the first installed match, moving from left to right?
No progress since ten years. Feel free to reopen with a tangible proposal.
