See here: 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 <thedoogs...@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 <panyc...@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 hul...@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@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/
