[Slackbuilds-users] requirements in README files

[Klaatu]

> 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
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/

J,
I would not mind following an informal "spec" for a portion of the README. I'm 
not interested in automated dep resolution for myself, but flexibility is a 
strength of Free Software, so let me know what you want to see in the README 
to make your scripts work, and I'll try to write my README files accordingly. 

Obvious exceptions would be when a dep is particularly optional or whatever, 
in which case I guess I'd just list it as a dep and assume that anyone using 
automated dependency resolution tools is foresaking optional-ness.

I imagine the easiest thing to do would be to stick the deps at the tail of 
the README file; presumably, you're looking for some kind of tell-tale Start 
line + some delimited list of deps + some kind of End-of-List marker, right? I 
could do that on any new builds I submit. (I won't go back and change any 
builds just for this, but I'd be happy to adapt them upon their next update.)

- klaatu