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.
I'm open to working on this, but first, I've a question: can someone actually name an example *other* than xorg-proto (which is a tiny set of header files)? To me, it's obvious that RDEPEND should include anything that our installed files may need (with the exception sometimes of e.g. very rarely used scripts), and for xorg-proto, we've done that for now in libX11 in: commit c2c8a65fb6252b1c1b974d6a9bdd46a1309d8dd7 Author: sin-ack <sin-ack@protonmail.com> Date: Sun Dec 29 09:02:09 2024 +0000 x11-libs/libX11: RDEPEND on x11-base/xorg-proto Without this, source packages fail to build against libX11 when installed as a binpkg due to missing transitive dependencies. Closes: https://bugs.gentoo.org/903707 Closes: https://bugs.gentoo.org/947059 Closes: https://bugs.gentoo.org/947999 Closes: https://github.com/gentoo/gentoo/pull/39886 Signed-off-by: sin-ack <sin-ack@protonmail.com> Signed-off-by: Matt Turner <mattst88@gentoo.org> Now, on that PR (https://github.com/gentoo/gentoo/pull/39886#issuecomment-2566722346), I gave a summary of the situation: """ The way it fails is pretty confusing and it's very cheap to have the header in RDEPEND, and avoids consumers having to workaround it via BDEPEND/DEPEND which isn't accurate. The real fix is to have BADEPEND of course, and I'm going to try get that into EAPI 9. It really is a runtime dependency, it's just that some definitions of "runtime dependency" mean "please only give me ELF-required stuff" and we're (IMO) optimising for that latter case at the cost of confusing build failures which waste people's time to investigate (as they're not obvious). """ So, my question is: can someone give me other examples than xorg-proto that actually motivate this? The request is not unreasonable but if it's only ever going to be used for one package... (or similarly things which are so cheap to have in RDEPEND, that anyone wishing to microoptimise should simply use package.provided)?
I'd actually be okay with having it in RDEPEND. If you're trying to build a minimal system, the first thing you'll chuck out is /usr/include, which is very easy. Perhaps I'm misunderstanding the problem though.
It's not completely unsystematic to have libX11 pull in the xorg-proto headers. We install header files with almost every package, and X11 is one of the few (or the only?) special cases. I don't think that saving space is an argument here. If it was, we would split off *-dev packages like Debian does (or have a use flag with the same effect).
As part of the [ChromeOS Bazelification](https://chromium.googlesource.com/chromiumos/bazel/+/HEAD/docs/getting_started.md) project, I had proposed (internally) adding a TDEPEND (transitive build time dependencies): > There is a third, but kind of unrelated idea which is adding a TDEPEND (transitive build time dependency). Right now when building a package, we need to inject all DEPENDs (build time dependencies) + the RDEPENDs (run-time dependencies) of those DEPENDs because there is no clear differentiation between "I need this to execute the library/binary" and "I need this so you can link against me". i.e., libFoo might have an RDEPEND on sed and libz. When building a package that links against libFoo, we don't actually need sed since we can't just exec the binary, so it's purely an RDEPEND. libz on the other hand might be necessary so the linker can find all the symbols. So having a TDEPEND we could declare libz as a TDEPEND, and leave sed and libz as RDEPEND, but we only ever inject libz into the package that depends on libFoo. This should help us cut down on our dependency tree. It was similar to BADEPEND, but more aggressive since the goal was to prune the transitive `RDEPEND`s for `DEPEND`s. When building a package very high in the graph, there can be hundreds of unnecessary RDEPENDs that get pulled in. I never ended up perusing this avenue though. I ended up implementing [Interface Libraries](https://chromium.googlesource.com/chromiumos/bazel/+/HEAD/docs/advanced.md#Interface-Libraries) which did solve some of the pain points TDEPEND was trying to solve. --- On the ChromeOS side we have the [opengles-headers](https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/acbfec9d206346d9bb09474a530128e59aaa420a/x11-drivers/opengles-headers/opengles-headers-9999.ebuild#1) package that I think falls into the same boat as `xorg-proto`.
As an additional example use case for BADEPEND: We could use it for some USE=vala stuff in the libraries. If a library that provides a .vapi file via USE=vala depends on another vapi file, then those dependencies are really only needed at build times, as vala is a compiled language. So with BADEPEND we could for example in dev-libs/libgdata change the RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?,vala?]" to RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?,vala?]" BADEPEND="vala? ( net-libs/libsoup:2.4[vala] )" and end up not needing USE=vala at runtime for whatever needs libgdata[vala] at build time (end-user applicaitons). Another theoretical case could be for USE=introspection, but that's not something BADEPEND could pull off alone, and it's probably not worth it. What I mean is, lets say rust needs introspection data at build time for compiling its gnome-ish *-sys crates, but then not anymore at runtime. So very similar to vala. However, unlike vala, some other package (e.g. python or gjs one) might need the recursive introspection data at runtime instead, so for that to work, we'd need to be able to declare that in case of this rust package, any recursive BADEPEND on USE=introspection are actually RDEPEND, which would be a whole lot more work (and probably a different *DEPEND) and outside this scope and probably pointless from a cost-benefit ratio aspect. I believe we've talked about some more use cases similar to xorg-proto too, involving headers, over on IRC, but I can't immediately recall what it was.
> there is no clear differentiation between > "I need this to execute the library/binary" > and "I need this so you can link against me" IMHO nice to distinguish these cases... +1 to consider TDEPEND.
(In reply to Alexander Kurakin from comment #14) Please keep replies substantive (or just remain in CC).
(In reply to Mart Raudsepp from comment #13) > RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?,vala?]" > to > RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?,vala?]" > BADEPEND="vala? ( net-libs/libsoup:2.4[vala] )" > and end up not needing USE=vala at runtime for whatever needs libgdata[vala] > at build time (end-user applicaitons). Did you forget to remove "vala?" or something?
(In reply to Sam James from comment #15) > (In reply to Alexander Kurakin from comment #14) > > Please keep replies substantive (or just remain in CC). Sam, agree, promise to be quiet. But let me please clarify my message. Its (non-)substantive premise was the importance (in my opinion) of Raul Rangel's message. Raul arguably wrote why there is a reason to discuss not only "what BADEPEND should be" and "do we need BADEPEND" but also "do we need exactly BADEPEND". Unfortunately, this more fundamental (in my opinion) question has became well... "not very commented" so far. May current discussion be a consequence of absence of such questions in the previous `*DEPEND` discussions? :) Unfortunately, I can't make even 20% of Raul's precise and brevity (and arguments). That's why I wrote a short message. Thanks and sorry. (Feel free to mark as obsolete.)
(In reply to Michał Górny from comment #16) > (In reply to Mart Raudsepp from comment #13) > > RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?,vala?]" > > to > > RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?,vala?]" > > BADEPEND="vala? ( net-libs/libsoup:2.4[vala] )" > > and end up not needing USE=vala at runtime for whatever needs libgdata[vala] > > at build time (end-user applicaitons). > > Did you forget to remove "vala?" or something? Yes. RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?,vala?]" to RDEPEND=">=net-libs/libsoup-2.55.90:2.4[introspection?]" BADEPEND="vala? ( net-libs/libsoup:2.4[vala] )"
