[Slackbuilds-users] REQUIRES info

Robby Workman rworkman at slackbuilds.org
Tue Aug 21 23:25:11 UTC 2012

On Wed, 22 Aug 2012 09:18:45 +1000
Christoph Willing <c.willing at uq.edu.au> wrote:

> On 22/08/2012, at 6:33 AM, <xgizzmo at slackbuilds.org>
> <xgizzmo at slackbuilds.org 
>  > wrote:
> [snip]
> >
> > Remember that in between releases master is our work in progress
> > branch and should not be considered stable or final. We will
> > summarize changes and new policies when the 14.0 branch is closer
> > to a usable state.
> At the moment, template.info contains the statement (about the  
> REQUIRES variable):
>      "It should not list anything available in Slackware."
> While new policies are not yet final, could we consider relaxing
> that particular stipulation i.e. could we make the the listing of
> official Slackware packages optional rather than forbidden?
> At worst, if we assume building is taking place on a fully loaded  
> Slackware system, then including Slackware packages in the REQUIRES  
> field would just be superfluous and certainly harmless (and optional).
> I have a use case where such information is actually useful rather  
> than superfluous. I run each build inside an LXC container which is  
> created just for that build. Rather than being a fully loaded  
> Slackware system, the container is a minimal system containing just  
> enough of the official Slackware packages to actually run a package  
> build script. At build time, based on the REQUIRES field, any
> missing packages (both Slackware and SBo) are first installed into
> the container. Of course the REQUIRES field is new so, so far, I've
> been modifying the .inf files myself to include that information.
> What do you all think? Any real problem with allowing official  
> Slackware packages in the REQUIRES field?

Sorry, but that one's a non-starter - in other words, no - we
will not be listing Slackware-provided packages in there. 

The only *possible* exception (and I don't even like this one)
would be the need for /extra/jdk/ - but I think we might import
that one into our tree for exactly that reason.   Time will tell.

To be clear, I'm sympathetic to your reasons, but it's just not
a slope on which we wish to start sliding.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20120821/f3b3ef62/attachment.asc>

More information about the SlackBuilds-users mailing list