<div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I know that some like to "optimize" the dependency list of SlackBuilds by not listing dependencies that are already included as dependencies of dependencies.  I would humbly ask to please not do this.  If a package directly depends on another package, explicitly list it as a dependency.  For those familiar with C programming, this is similar to the question of which headers to include in your source files (whether or not to list headers that are already included by other headers).<br>
<br>
Why?  2 reasons:<br>
<br>
1) You don't have to track the dependency list of your dependencies (and their dependencies, etc.).  It shouldn't matter if a dependency 3 levels deep drops a dependency on something you actually need.<br>
<br>
2) Slackrepo's rebuild logic depends on it.  When a package is updated, slackrepo builds it and then rebuilds all packages that depend on it.  It does not, however, rebuild packages that depend on rebuilt packages.<br>
<br>
For me, the fwupd build failed with error:<br>
<br>
protoc-gen-c: error while loading shared libraries: libabsl_log_internal_check_op.so.2508.0.0: cannot open shared object file: No such file or directory<br>
<br>
The reason is that abseil-cpp was updated, and slackrepo duly rebuilt protobuf3.  However, it did not rebuild protobuf-c, as protobuf-c only lists protobuf3 as a dependency (and not abseil-cpp).  fwupd depends on protobuf-c.  The (trimmmed) slackrepo dependency tree output is:<br>
<br>
Dependency tree:<br>
system/fwupd (update for version 1.9.34)<br>
  libraries/protobuf-c (ok)<br>
    development/protobuf3 (ok)<br>
      development/abseil-cpp (ok)<br>
<br>
After explicitly telling slackrepo to rebuild protobuf-c, the fwupd build succeeded.  I can thus infer that protobuf-c directly depends on abseil-cpp.  In other words, whenever abseil-cpp is upgraded protobuf-c needs to be rebuilt.<br>
<br>
Of course, maintainers are free to do as they wish.  I ask because I prefer not to rebuild all my SBo packages each week, instead (re)building only what is necessary.  This happens infrequent enough that I usually forget this is the issue, wait a week for the build to be fixed, and after further investigation remember that some of the dependencies need a manual rebuild.<br><br></blockquote><div>AFAIK, this 'optimization' is currently a SBo policy (needs confirmation)..</div><div>In addition to your suggestion, I think it would be interesting to have an entry like 'AFFECTS=""' in the .info files, where the dependees could/should be listed. This could be used by slackrepo/sbopkg/sbotools for automation to list and/or rebuild the dependees.</div><div><br></div><div>Regards,</div><div>Fellype</div></div></div>