[Slackbuilds-users] Please list all direct dependencies as dependencies

[Tim Dickson]

On 29/04/2026 14:43, Erich Ritz wrote:
> On Wednesday, April 29th, 2026 at 4:58 AM, Tim Dickson via SlackBuilds-users <slackbuilds-users at slackbuilds.org> wrote:
>
>> the submission rules state not to declare deps of deps.
>>
>> whatever tool you use, way you can't get away from the need to rebuild
>> other packages from time to time. Usually if there is a major version
>> change so the api/abi may changel and that may require rebuilding some
>> trees.
>>
>> One issue with declaring all sub deps in a package is maintainers having
>> to keep track of all the sub deps and potential optional deps.
> No, that is not what I am proposing at all.  I am asking to declare all direct dependencies.  Example: A depends on (uses features of, links to, etc.) B and C.  B depends on C and D.  A should list B and C as deps, and B should list C and D as deps.  A should not elide C as a dep simply because B also depends on it.  A should not list D as a dep.
in your example the current method would be listing just B as a dep of 
A, as having B will include C and D, and if B changed it's deps to not 
need C, then A wouldn't compile because it also needed C.

ok. I've come across that issue. the challenge then becomes knowing 
which libs are directly needed and which are indirectly needed. that 
information is not usually provided. Often a project may either list all 
the deps, or only direct deps, and assume that those deps will have 
their deps installed etc, down the tree. it is much harder for sbo 
admins to verify if an inclusion is valid as you have to go through all 
the source code to see how functions from libs are being called. it 
might work if you only looked after 1 or 2 packages, but verifying 
1000's of packages is not viable an awful lot of source code to check.
it's sort of useful to know but a headache to maintain.
>> increasing the work for the maintainers, and making it very difficult to
>> stay up to date, due to daisy chain effects of one lib changing it's
>> dep, causing half the repo needing to be updated. That is not a
>> sustainable way to operate, as the sbo admins would be flooded with
>> updates all the time, and due to the release cycle, changes would
>> propagate over weeks. Our current method of only listing direct deps,
>> and if something breaks then fix it is more manageable than forcing
>> cascading updates if one lib changes it's deps.
>>
>> on approach is rebuild and see if it works. if not, rebuild tree. you
>> can use tools like sqg to generate dep trees, just bare in mind any
>> "optional deps".
>>
>> regards Tim
>> _______________________________________________
>> SlackBuilds-users mailing list
>> SlackBuilds-users at slackbuilds.org
>> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - https://slackbuilds.org/faq/
>>
>>