[Slackbuilds-users] Clarification of REQUIRES and dependencies
Willy Sudiarto Raharjo
willysr at slackbuilds.org
Thu Nov 27 12:39:08 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My answer below is my personal opinion and do not represent other admins
> The disagreement occurs when package 1 depends on packages 2 and
> 3, and package 2 depends on 3. Should 3 be listed in 1's
> REQUIRES?
for me, it's a no
When you want install 2, you will need to install 3 and by then you
will have 2 and 3 installed.
Adding all deps may not be a problem for a package which doesn't have
so many deps, but consider packages that have LOTS of deps, it will be
a huge job for the maintainer to track all "direct" deps.
> What is the original intention of that guideline? Can that
> sentence be updated to distinguish these two interpretations?
from my point of view, the sentence was made to simplify things as
maintainer. Not all of us can track every "direct" dep for a package,
so by listing 1st level dependency, it simplifies our duty. We assume
other maintainer did their job to track their package's dependencies
and we trust their decision and include their packages.
> Possibly a more important question: Does it matter? Are there
> any SBo tools out there that need the dependency info to be
> underlinked? Are there any tools that would benefit by not
> underlinking, or are broken by underlinking?
this is not really related to any SBo tools out there since this
decision was made long before there's any sbopkg or any other
automatic tools.
> Personally I like having all of the dependency interrelations
> available to me, to know how all of the packages depend on each
> other, and I hate having parts of it stripped out to meet Willy's
> interpretation or some specific tool's needs. If some tool needs
> the underlinked info, then that can be automatically generated from
> the complete info -- that's what we have computers for, right?
for me, it doesn't really matter since sbopkg + sqg does the job for
me, but again, we are not talking about tools. SBo will work with(out)
any tool, but at the end, it's our (maintainer) job to handle our
packages.
- --
Willy Sudiarto Raharjo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlR3G2wACgkQiHuDdNczM4Hz2ACfW3Eq7mvWSPQGIRhplzI75J8H
nuYAoJGOsEA0pH3TzTNEKL5uiRKgCZEX
=UK2p
-----END PGP SIGNATURE-----
More information about the SlackBuilds-users
mailing list