On 6/14/26 07:32, Andrea Cocito wrote: > > On 14 Jun 2026, at 06:07, Mark Millard <[email protected]> wrote: >> On 6/13/26 20:21, Bugs Beastie wrote: >>> [….] >>> If an app depends on libfoo that depends on libbar: >>> app -> libfoo -> libbar >>> Should the port of app add LIB_DEPENDS only on libfoo or on both libfoo and >>> libbar? >>> [...] >> In other words(?): Where does the responsibility for handling the >> transitive closure of the dependencies reside? > > Hi, from a principle point of view the port should add only libfoo unless it > also uses directly libbar. > > This because tomorrow morning the maintainer of libfoo might decide to stop > using libbar and use libbaz instead, so your app does not need libbar anymore > and dependency becomes implicitly: > app -> libfoo -> libbaz.
In somewhat more detail about the staging . . . The source code's change time frame (including Makefiles and such) is not what leads to the change finally taking effect. Two more stages contribute in order for the change to take effect in some context: ) a new build occurs (including the updated dependencies) ) the new builds are installed in the context But: Trying to keep 36000+ port-packages up to date manually for indirect dependency tracking via source code editing would be error prone and a huge effort, needing to update all the relevant explicit indirect dependencies that happen to be in the 36000+ port packages. The build time frame is better for generating more accurate dependency tracking information. The install time frame is when the adjustments to changes take effect for a context. 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. > > Just my two cents, > > A. > > > > -- === Mark Millard marklmi at yahoo.com
