I think that was mentioned before but I don't see any bug. The concept stolen from exheres but simple as it could be: add additional, optional BADEPEND variable. This variable would specify additional build-time dependencies which would apply to other packages having the particular package in their build-time dependencies. Consider the following example: 1) building against libfoo requires foo-headers, 2) in pure runtime, libfoo doesn't require foo-headers, 3) bar wants to build against libfoo. Right now, bar is responsible for having DEPEND="foo-headers". This may be ok but at some point actual dependencies of libfoo may very and all ebuilds depending on it will have to be kept in sync. With BADEPEND, libfoo will just BADEPEND="foo-headers". When installing bar, PM will scan its DEPEND and find libfoo there. Then it will scan libfoo's BADEPEND and add foo-headers for bar's build-time. This is a pretty common case with X11 (where -proto headers are separate packages). It also applies to a lot of packages which are supposed to be built through pkg-config (though it could be negligible whether pkg-config should be enforced by a package or configure script calling it).
(In reply to comment #0) > I think that was mentioned before but I don't see any bug. The intention seems to match the summary of bug 201499, though the approach that's initially suggested in bug 201499 is more like exheres' unified DEPENDENCIES variable. Also, note that the HDEPEND variable discussed in bug 317337 has a different meaning from BADEPEND, though it uses a similar approach to BADEPEND.
yeah, sounds like a dupe of bug 201499. i don't think "BADEPEND" is a good short name either ... i see "bad depend".
Hmm, I think I didn't mention it clearly in the initial comment but this should probably somehow get propagated to sub-dependencies. In other words, all packages having DEPEND on libfoo get its BADEPEND as well. Then, all packages having DEPEND on those packages, get libfoo's BADEPEND as well, and so on. Not sure how to implement it best.
This has been suggested under the name CDEPEND previously: https://archives.gentoo.org/gentoo-dev/msg_db4986470a316a3653bfecd593d5007b.xml
*** Bug 298759 has been marked as a duplicate of this bug. ***
Virtuals are more flexible than the BADEPEND. For example, in discussion related to bug #503802, it was noted that if we later find that virtual/podofo-build works for calibre but not some other reverse-dependency of podofo, then we can always create a different virtual to put in DEPEND of said reverse-dependency: http://article.gmane.org/gmane.linux.gentoo.devel/93428
(In reply to Zac Medico from comment #1) > The intention seems to match the summary of bug 201499, though the approach > that's initially suggested in bug 201499 is more like exheres' unified > DEPENDENCIES variable. Also, note that the HDEPEND variable discussed in bug > 317337 has a different meaning from BADEPEND, though it uses a similar > approach to BADEPEND. If you use HDEPEND to mean what Ambroz was calling TDEPEND, as discussed in that bug, then it's exactly the same thing, only with recursive dependencies, which could either be a sub-slot operator, syntactically, or a CDEPEND; either way it'd cover what mgorny is after, which is going to require a (CHOST) HDEPEND set for the ebuild in question. In fact, x11-proto/xcb-proto was the motivating header-dependency for bug 317337, and bug 298759 has been marked a dupe of this one, so I think it's very much on-point. The main thing I care about is we don't lose sight of CBUILD/CHOST/CTARGET under the hood, which very nearly happened with 317337.
I don't think that bug 752153 is related. That one is about CBUILD type direct build dependencies, while this bug is about indirect CHOST type dependencies.
