[sbopkg-users] [Slackbuilds-users] sbopkg and the README/.info files (REQUIRES line)
slakmagik
slakmagik at gmail.com
Sat Oct 6 02:26:26 UTC 2012
On 2012-10-06 (Sat) 08:49:27 [+0700], Binh Nguyen wrote:
> On Fri, 05 Oct 2012 17:41:12 -0700
> Phillip Warner <pc_warner at yahoo.com> wrote:
>
> > You could potentially add a new option to sbopkg to generate a queue
> > on the fly by recursively making use of the REQUIRES in the .info file
> > of the selected SlackBuild and its respective required slackBuilds and
> > so on. I wouldn't recommend building directly from this. Rather the
> > queue would have to be processed as they are now. In the GUI a
> > "Generate queue" option could be in the menu while viewing any
> > SlackBuild. The cli could use maybe a 'Q' and a filename to save the
> > queue to.
> >
> > --phillip
>
>
> If you look at the syntax of sbopkg queuefiles, it's not just simply a
> list of dependencies but ON/OFF flags, dep options, etc. So we cannot
> just utilize REQUIRES like that but some modifications are needed.
>
> Ideally, I think Mauro Giachero's queuefiles git repo should be
> maintained in parallel with slackbuilds.org git repo. It would only be
> updated when new SlackBuilds be added though. With the new REQUIRES,
> maintaining a repo like that would not be so difficult as before I
> believe.
>
> -- Binh
1st, I just sent the initial mail on this to both lists because it was
following up on the release announcement (I should have actually posted
both my 'oops' mails as actual follow-ups to it - sorry about that) but
I don't want to clutter the slackbuilds list with any more
sbopkg-specific stuff than I already have. ;) If there's any more
discussion I'd direct it solely to the sbopkg list.
As far as the deps, that's kind of the third rail for me. Slackware ==
no-dep-handling. I have no interest in putting anything into the core
sbopkg that handles deps or generates queue files or whatever. It
processes them, but that's it. So I think Binh's correct - it should
make it easier for Mauro to generate his queuefile repo or for others to
do so if he's not still doing it but that's about it and doesn't concern
sbopkg. I get that the new line enables the SBo website to do neat stuff
with the hyperlinks and all and it probably makes it easier for the
admins to check/maintain the dep list but I think those should be the
primary uses of the field.
More information about the sbopkg-users
mailing list