On 6/14/26 08:58, Andrea Cocito wrote: > On 14 Jun 2026, at 17:13, Mark Millard <[email protected]> wrote: >> I would claim that the above effectively means that the responsibility >> for indirect dependencies essentially needs to be split across the >> automated build process and the automated installation process and, at >> the scale involved, cannot reasonably/generally be handled at the source >> code stage for tracking the indirect dependencies. > > Hi, > > I totally agree, this is why I think that (again: unless you *directly* > use stuff from some sub-dependency, and then it’s not an indirect > dependency, it’s a direct one) you should not manually insert sub- > dependencies in the port you maintain. > > It’s already quite complex this way (especially when things like python > which has "it’s own dependency layer”, or dbus which depends on it just > for a small compile-time component get in…), handling indirect > dependencies in each port would be unaffordable IMHO. > > But, as correctly said, let’s wait for the final statement from who > knows more. > > A. >
Something I forgot to deal with in my description: There are also, two dependency structures, where I was implicitly only explicit about the second one below: ) build time dependencies ) run time dependencies Build time does involve its own, possibly temporary, installations of things used. [poudriere(-devel) is an example of using temporary installations in an only-as-needed manner. Forms of direct Makefile usage in the overall live environment are not.] Non-build end-user installation activity is not involved for build time dependency tracking. But part of my wording would apply to both contexts: "at the scale involved, cannot reasonably/generally be handled at the source code stage for tracking the indirect dependencies" (both build-time and run-time) -- === Mark Millard marklmi at yahoo.com
