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

[Erich Ritz]

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.

> 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/
> 
>