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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/