On Wednesday, April 29th, 2026 at 4:58 AM, Tim Dickson via SlackBuilds-users 
<[email protected]> 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
> [email protected]
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 
> 
_______________________________________________
SlackBuilds-users mailing list
[email protected]
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Reply via email to