[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.
-RW
-------------- 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