Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 392239

Summary: [Future EAPI] BADEPEND - built-against deps
Product: Gentoo Hosted Projects Reporter: Michał Górny <mgorny>
Component: PMS/EAPIAssignee: PMS/EAPI <pms>
Status: CONFIRMED ---    
Severity: enhancement CC: chewi, esigra, tsmksubc
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=379545
https://bugs.gentoo.org/show_bug.cgi?id=298759
https://bugs.gentoo.org/show_bug.cgi?id=503802
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 174380    

Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-11-28 08:33:11 UTC
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).
Comment 1 Zac Medico gentoo-dev 2011-11-28 16:42:32 UTC
(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.
Comment 2 SpanKY gentoo-dev 2011-11-28 18:32:57 UTC
yeah, sounds like a dupe of bug 201499.  i don't think "BADEPEND" is a good short name either ... i see "bad depend".
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-09-04 09:15:39 UTC
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.
Comment 4 Ulrich Müller gentoo-dev 2014-06-26 08:28:17 UTC
This has been suggested under the name CDEPEND previously:
https://archives.gentoo.org/gentoo-dev/msg_db4986470a316a3653bfecd593d5007b.xml
Comment 5 Ulrich Müller gentoo-dev 2014-07-07 17:13:21 UTC
*** Bug 298759 has been marked as a duplicate of this bug. ***
Comment 6 Zac Medico gentoo-dev 2014-10-16 21:03:38 UTC
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
Comment 7 Steve L 2015-07-02 04:40:25 UTC
(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.