[Slackbuilds-users] sbopkg and the README/.info files (REQUIRES line)

[J]

Quoting Christoph Willing <c.willing at uq.edu.au>:

> On 06/10/2012, at 12:26 PM, slakmagik <slakmagik at gmail.com> wrote:
>
>> 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 guess we all have a personal interpretation of what Slackware is.
>
> Certainly there is no dependency handling in the official pkgtools -  
> nothing like what exists in yum, apt-get etc. However, please see:
>      
> http://www.linuxquestions.org/questions/interviews-28/interview-with-patrick-volkerding-of-slackware-949029/
> in which Patrick Volkerding is quoted as saying (about what tools  
> are used to keep track of, and update, the packages in Slackware):
>
> "We do have a couple of tools that were written by Stuart Winter  
> that we use to find packages that link against a given library, or  
> binaries that need to be recompiled because libraries that they were  
> linked against have gone missing."
>
> Interpret that as you wish. To me, its clear from that quote that  
> some sort dependency checking is going on in the creation of each  
> Slackware distribution.
>
>
>> I have no interest in putting anything into the core
>> sbopkg that handles deps or generates queue files or whatever.
>
> Thats fair enough - your interests are yours to have.
>
> However, including the premise that "Slackware == no-dep-handling"  
> as further justification doesn't seem totally right to me. Its a  
> premise that many people make and/or take for granted; but its not  
> entirely correct.
>
>
> chris
>
>

"If you only have a hammer, you tend to see every problem as a nail"

sbopkg does not fundamentally care about requirements; given the  
developers' obvious disinterest in this, that is how it should be -  
with their justifications being irrelevant, in my opinion. Those who  
want a tool which utilizes the REQUIRES info may use my sbotools  
(dawnrazor.net/sbotools), or there is also a new tool now called  
sbodeps (www.iquidus.org/sbodeps) (haven't tried it, can't comment on  
it). We are also all free to write our own tools to work with  
slackbuilds.org which meet our ideals of How It Should Be Done, and we  
also are all free to modify a copy of sbopkg to suit our tastes - or  
even fork it. Let's bear these points in mind. :)

Incidentally, having manually maintained queue files with lists of  
requirements in appears to me to be another example of seeing the  
problem as a nail due to only have a hammer to approach it with.

J