[Slackbuilds-users] Clarification of REQUIRES and dependencies

[Bojan Popovic]

Hi,

Thanx for the heads up. It's nice to read about the original
intentions and it makes sense. But you probably also predicted people
will use that in way thay find the most practical. :)

Although, I agree: dependency resolution is hard to automate,
especially in small teams. And even in big teams like Debian it turns
out to be cludgy and bloats the system. And then you enter into the
circle of constant and continous automation and abstraction of
abstraction of abstraction. And automation of the abstraction that
requires additional abstraction to make sense, and so on. That's why I
like Slack. It's already simple. There is no need for the additional
kludge.

That being said, REQUIRES does provides a device for implementing at
least some level of dependency resolution. But in no way it is possible
to base a complete fool-proof system around it. I see it as more of a
build helper than actually auto-dependency utility. 

That's why I think sbopkg's half-manual approach works great. And the
author doesn't even encourage the usage of sbopkg for that. Although
you can do it and it works great. Of course, with a manual
intervention here and there. 

Anyway, you guys are doing the great job and I hope you won't give in
to the popular demand. We don't need auto-dependency
hell/kludge/bloat in Slackware. :) 

Although having a device for at least some half-automation is great
thing. Especially as any dependency conflicts or recursion can be
solved manualy. :)

Thanx for the great job and cheers,

Bojan.

On Fri, 28 Nov 2014 22:06:12 +0100
Heinz Wiesinger <pprkut at slackbuilds.org> wrote:

> 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: 819 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20141129/27d8abb4/attachment.asc>