Summary: | [Future EAPI] BADEPEND - built-against deps | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Michał Górny <mgorny> |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | chewi, esigra, rrangel, sam, 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
2011-11-28 08:33:11 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. 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. |