RFC: Dependencies cant get reused

[ShalokShalom]

This Konsole shows you the output from libX11 build
As you can see, does the program complain that libxcb miss libpthread-stubs

The file shows you, that i use that one in pkg_deps.

I know that its possible to build X11 without all those dependencies in practically each single package, while that is to me until the only possible way i can see.

The pkg_deps line you see here is similar to nearly each other X package i build until.
Otherwise does pkg-config always claim, that these packages are not found.

So, it seems to me, that the usage of those packages as dependencies are not inheritable.

Is it possible that the usage of pkg_lib_dirs and/or pkg_bin_dirs can help here?
If yes, which directory?

[eeyun]

This is very likely a hidden dependency that doesn't exist in an upstream package and not an issue of transient dependencies. In this specific case, you're going to want to look at the package in question to determine if it's missing some dependency that gets used by downstream software. Because the upstream packages is also using pkg-config its likely where that comes from!

[ShalokShalom]

First of all, this pack with 2-3 dependencies in KaOS.
Secondly, it happens for all the X11 packages from this one on or so.
Third, i guess that you closed that issue means that you assume that this hint will solve the it for me, while this is not the case. Can we close issues once they are solved, as opposed to "think it is solved?"

EDIT: Paul Adams explained me, that i have to add all depends - including depends of depends - into each pkg_deps list. Again, this is something i am not used to do in Pacman.

He also means, that this may can get solved by rebuilding pkg-config for Habitat specifically.

[baggerspion]

Almost... it is not a rebuild of pkg-config, it is a rebuild of the environment. When we run build inside the studio, the contents of pkg_deps()/pkg_build_deps() is used to populate the PKGCONFIG environment.

What I would propose is that environment var should populate with the entire stack of PKGCONFIG deps and then we do not need to include the entire stack of deps in the plan.sh. Perhaps that var gets updated post-install, rather than at build time?

[reset]

@ShalokShalom I'm sorry that we weren't explicit enough in our answer here. You need to explicitly list all build and runtime deps - by design we want things to be as explicit as possible. If this isn't the solution, we believe the next likely culprit is a packaging issue with a package that isn't in the core origin which is why we closed this issue. You should reach out to the maintainers of those packages for support.

If there is a missing feature or a bug in the build system itself we of course can provide a patch!

[ShalokShalom]

@reset I add all the build and runtime deps, as written and shown. As described, is it about the depends of the depends.

As you can see, are there some runtime packages who are required by Habitat and not by Pacman.

This is, so far as i can see the issue, since a plan.sh like to get all its sub-deps added as well, which feels uncomfortable and unnecessary, especially when i think about packaging some thousand GUI packages, who use high amounts of sub-deps.

What do you think about the idea from Paul? 🥇

[adamhjk]

We could revisit this decision, but our position is that if the top level binary has the link, it must be explicit. In the case of Adch, they are fine with the "hidden" dependency. We decided the opposite - that we want top level deps to be explicit, since they are the things you really care about for the software in question.

If we switched, you risk having a dependency add a feature, which pulls in a library, which then results in the top software compiling options in that in a previous build were disabled (because the dep they looked for in autoconf was false).

Habitat decided to value the correctness and safety over the faster/looser approach. Right now, I'm inclined to keep it that way, but I'm open to discussion.

[adamhjk]

If we wanted to allow that, we could populate it like Paul says. I am worried about the transitive injection and subsequent accidental change to a library.

[ShalokShalom]

And which way will work?

[adamhjk]

We need more information. Specifically, we need to understand if your example application calls libXau, libpthread, etc. if it does, then we don't have a problem with our system (because the top level application does, in fact, have those deps). It works in Arch because those libraries are on disk due to a transitive dep already having them.

This is an important design difference between arch and habitat, and one we are unlikely to change if it's behaving as we specify above.

If the top level application doesn't make those calls, or doesn't need those libraries, then we should investigate if we have a bug.

[eeyun]

@ShalokShalom would it be possible to get the info that adam is asking for above? Specifically, we need to know if the example application calls libXau and libpthread (or any of the dependencies mentioned) before we can effectively continue community dialogue around this!

Thanks!

[ShalokShalom]

I already deleted a lot of the packages in order to rebuild them, since the issue was already closed. So I will close it again and open a new one, if one emerges.

I was asking about the transient packages, in this comment 2 weeks ago. Adam made clear in another post that nothing will change about the depends of depends issue, so this one is solved too.

Thanks a lot