[Slackbuilds-users] requirements in README files

Mon Jul 9 23:00:02 UTC 2012

I have to agree with this. 95% of the time I vastly prefer the classical
Slackware approach to package management to what I've seen in other distros
or other Unix(-like) systems. However there are a few cases where
build-time or run-time dependency trees can get pretty crazy. Many of the
multimedia packages are prime examples of this, especially the video
editors which depend on long chains of audio and video codes, libraries,
and frameworks. Try building avidemux or cinelerra on a clean Slackware
system without looking at a slack-required file and only using the hints in
the README files.

I'm not saying it needs to be mandatory, but if a maintainer would like to
go to the extra effort to include it then why shouldn't it be allowed?

On Mon, Jul 9, 2012 at 6:32 PM, Christoph Willing <c.willing at uq.edu.au>wrote:

> I believe the OP was just suggesting a less ad-hoc way to describe build
> dependencies.
>
> Of course thats not always uncomplicated; nevertheless for some large
> percentage of software, the prerequisite packages required to build some
> new software are quite clear. Why not accommodate these cases? Whatever the
> format for describing the prerequisites, any builder has the option of
> ignoring them.
>
> In my own situation, I add a PREREQUISITES="...." line to the SBo's .info
> file. This can be used (or not) at build time to ensure that the
> prerequisite packages are installed. The parsing & checking can be done in
> the .SlackBuild script itself or, if purity is paramount, can be left to a
> separate wrapper script which parses the .info file, checks the
> prerequisite packages are installed and then runs the .SlackBuild.
>
> Yes, "garbage in, garbage out". If the PRERQUISITES field contains
> rubbish, its not useful; but thats also true of anything in existing SBo's.
>
> The same really applies for slack-required files too (for runtime
> dependencies). They're not compulsory! /sbin/installpkg & friends ignore
> them; so can everyone else. Why should we prevent SBo authors including
> them and why should we prevent arbitrary users reading them? Of course
> they're useless if they contain bogus information but we generally trust
> SBo authors' scripts to be otherwise well behaved etc. There's nothing
> "dangerous" going on here, just more knowledge. If they offend you, don't
> look.
>
>
> chris
>
>
>
> On 10/07/2012, at 6:56 AM, T3slider wrote:
>
>  See here: http://slackbuilds.org/faq/#**deps<http://slackbuilds.org/faq/#deps>
>> The omission of parsable information is an intentional one as far as I
>> know. In order for dependency resolution to come to SBo, there would
>> need to be a way of identifying mandatory vs. optional dependencies.
>> Additionally, if there is special information regarding a certain
>> application or SlackBuild (for example, if a unique user is
>> needed/advised to build/run the application) then this would be
>> impossible to portray in a parsable format. Significant planning is
>> required to produce a good template to follow that provides for all of
>> the complications of dependency resolution, and further, another level
>> of verification on the behalf of the SBo admins would be required to
>> ensure that this information is correct.
>>
>> slackbuilds.org is not setup to be a do-everything script repository --
>> users are expected to read the README files. If you are blindly
>> accepting the options given by a dependency resolver, then you likely
>> have not read the READMEs and are expecting everything to just work.
>> With sbopkg I currently have no need for anything more sophisticated --
>> I can read the README for each element, ensure that requirements are
>> met, and just add each dependency to a queue. I don't know what you're
>> doing but it certainly doesn't take me hours to do, with the possible
>> exception of setting up my system after a new Slackware release, which
>> requires going through a whole new SBo repository and making sure things
>> will work (and waiting for things to compile). And if you really are too
>> lazy to read the READMEs there are queuefiles available already.
>>
>> I maintain only a few SlackBuilds but in those there is information that
>> I cannot accurately portray in a standardized format (for example,
>> remind has tons of configure options, and a *run-time* dependency that
>> may or may not be needed depending on your needs). If you're not reading
>> the READMEs for a SlackBuild then you're asking for trouble. Your
>> solution may work for trivial software but in the real world dependency
>> resolution requires an awful lot of work.
>>
>> On Mon, Jul 09, 2012 at 03:24:52PM -0500, J wrote:
>>
>>> Quoting Doogster <thedoogster at gmail.com>:
>>>
>>>  You're trying to parse requirements out of README files?
>>>>
>>>> Are you trying to to write something like Portage for SBo?
>>>>
>>>
>>> No, something like FreeBSD's pkgtools:
>>>
>>> http://dawnrazor.net/sbotools/
>>>
>>>
>>> Quoting Yaroslav Panych <panych.y at gmail.com>:
>>>
>>>  I am absolutely against of such enforcement. Because next step will be
>>>> automatic dependency resolver and I don't think somebody wants it.
>>>>
>>>
>>> This is a leap of login akin to saying that publicly available
>>> condoms will lead to no children being born. I have written the
>>> option to parse requirements into sbotools because the current
>>> method - look up sbo, find list of requirements, open new tab, look
>>> up requirement, find list of requirements, etc etc, is a usability
>>> and sanity failure. The fact is that the sort of consistency in the
>>> READMEs in which I'm interested is good for the users who don't care
>>> to utilize such an option as well, because it's easier to identify -
>>> pattern recognition, basic human interface to the world.
>>>
>>>  think it will bring more harm than profit. I know how hard to
>>>> determinate requirements manually, but I sure it worth to do. It will
>>>> filter noobs aside(less noobs - less maintainers headache, less
>>>> maintainers headache - better maintainer work).
>>>>
>>>
>>> Requirements would still be determined manually. The only change I
>>> am proposing is consistency in documenting them.
>>>
>>> Quoting Hullen at t-online.de (Helmut Hullen):
>>>
>>>  The README is created from the author/maintainer of the program. The SBO
>>>> maintainer should not change it.
>>>>
>>>
>>> And yet, other parts of slackbuilds will get changed by maintainers.
>>>
>>>  This requires perl-Params-Validate, perl-DateTime-Locale,
>>>>> perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel
>>>>> perl-Math-Round.
>>>>>
>>>>
>>>> That's another problem - these informations should be put into "install/
>>>> slack-required". And that could be a job for the SBO maintainer.
>>>>
>>>
>>> These would be a valid solution, but I'm not sure it makes a lot of
>>> sense, personally. It not only duplicates the data, but I'm
>>> apparently the only person who is dead sick and tired of crawling
>>> through 20 tabs of slackbuilds to get the requirements together for
>>> a single one, and who doesn't feel that sbopkg and queue files are a
>>> solution that fits the problem. And that's fine, and doesn't warrant
>>> an individual file - though it would be nice. But consistency
>>> amongst READMEs is easy to achieve, better for usability, and as
>>> noted, there is already a precedent since other files will get
>>> edited.
>>>
>>> J
>>>
>>> ______________________________**_________________
>>> SlackBuilds-users mailing list
>>> SlackBuilds-users at slackbuilds.**org <SlackBuilds-users at slackbuilds.org>
>>> http://lists.slackbuilds.org/**mailman/listinfo/slackbuilds-**users<http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users>
>>> Archives - http://lists.slackbuilds.org/**pipermail/slackbuilds-users/<http://lists.slackbuilds.org/pipermail/slackbuilds-users/>
>>> FAQ - http://slackbuilds.org/faq/
>>>
>>>  ______________________________**_________________
>> SlackBuilds-users mailing list
>> SlackBuilds-users at slackbuilds.**org <SlackBuilds-users at slackbuilds.org>
>> http://lists.slackbuilds.org/**mailman/listinfo/slackbuilds-**users<http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users>
>> Archives - http://lists.slackbuilds.org/**pipermail/slackbuilds-users/<http://lists.slackbuilds.org/pipermail/slackbuilds-users/>
>> FAQ - http://slackbuilds.org/faq/
>>
>>
> Christoph Willing              +61 7 3365 8316
> Research Computing Centre
> University of Queensland
>
>
>
>
> ______________________________**_________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.**org <SlackBuilds-users at slackbuilds.org>
> http://lists.slackbuilds.org/**mailman/listinfo/slackbuilds-**users<http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users>
> Archives - http://lists.slackbuilds.org/**pipermail/slackbuilds-users/<http://lists.slackbuilds.org/pipermail/slackbuilds-users/>
> FAQ - http://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20120709/d1f7712c/attachment-0001.html>