[Slackbuilds-users] Clarification of REQUIRES and dependencies

[Heinz Wiesinger]

On Thursday 27 November 2014 03:13:01 Kyle Guinn wrote:
> Willy and I have a disagreement about this line of
> http://slackbuilds.org/guidelines/
> 
> "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
> examples:
> https://wiki.mageia.org/en/Overlinking_issues_in_packaging
> https://wiki.mageia.org/en/Underlinking_issues_in_packaging
> 
> 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
> interpretations?
> 
> 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.

THAT SAID...

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 
happen...
-) 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.

Cheers,
Heinz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20141128/933f552b/attachment.asc>