[Slackbuilds-users] Clarification of REQUIRES and dependencies
pprkut at slackbuilds.org
Fri Nov 28 21:06:12 UTC 2014
On Thursday 27 November 2014 03:13:01 Kyle Guinn wrote:
> Willy and I have a disagreement about this line of
> "The content of REQUIRES should only be first level dependencies (i.e.
> no deps of deps)."
> 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?
> It's similar in context to overlinking/underlinking for libraries. If
> you don't know what that is, these two pages describe it with
> I am interpreting this guideline as "Do not overlink", as in don't
> list the entire tree of dependencies, just those with a depth of 1
> ("first level"). Willy is interpreting it as "Underlink wherever
> possible" (similar to the indirect case on that second page) and will
> remove a depth=1 dependency from REQUIRES if it happens to appear at
> some depth > 1 (a "dep of dep"). What is the original intention of
> that guideline? Can that sentence be updated to distinguish these two
> 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?
Here's my *personal* stance on this.
It's abundantly clear from the replies in this thread that users see REQUIRES
primarily as a means for dependency resolution. Various tools facilitate
REQUIRES for that very same purpose as well. But, that is not actually its
primary function. REQUIRES was introduced as a means to make script approval
after submission easier. It is a way for us admins to know the minimum set of
other applications/libraries to install in order to be able to verify the
SlackBuild successfully. As such Willy's interpretation of what should go into
REQUIRES makes perfect sense, as it's just more convenient that way for us.
We had a long and thorough discussion among the admins before introducing
REQUIRES and afaicr the common agreement was that there's no possible way we
can make REQUIRES work perfectly for dependency resolution. Having to consider
runtime deps, optional deps, conflicting deps, suggested deps. All existing
dependency management systems are broken for that very fact, implementing our
own would fare no different from those. And it's the freedom of not having to
deal with that mess that makes me love Slackware so much, and from multiple
posts on LQ, this mailing list and many other places, so do many other
slackers. So we decided whatever becomes of REQUIRES should primarily suit the
approval processes of SlackBuilds.org. It could still be used by tools, as
long as its limitations are kept in mind.
The stance of SlackBuilds.org admins from the very beginning has always been
"This is how we do it. We have good reasons for it, but we're not all-knowing.
Make your case and we may consider adapting our processes." In fact, this is
exactly how REQUIRES got introduced in the first place. It was a response to
users making their case and us adapting our processes. There's no reason we
can't reiterate over that. As long as simple things are kept in mind:
-) (proper, complete, etc) dependency resolution is just not going to
-) don't think about installing packages, think about maintaining SlackBuilds
For example, Urchlay's claim for reverse depencency mapping makes perfect
sense here. I extensively use this when updating some of my lower level libs
to make sure I don't break anything, or to hunt down fixes for things I do
break. It can also help admins in the very same ways. As a matter of fact, we
already do have reverse dependency mapping exposed in our own tooling.
So if we can come up with a good and clear definition of what should go into
REQUIRES so that reverse dependency mapping is reliable, I have absolutely no
problem with supporting it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 213 bytes
Desc: This is a digitally signed message part.
More information about the SlackBuilds-users