Another thing which has been mentioned a few times, and which I have
considered off and on myself, is a fork of the repo. There are several
reasons I have not pursued this idea; it constitutes an amount of work
which would keep me busy doing that for an unrealistic amount of time,
or it requires a parser able to grok our random requirement listings,
and I'm back to square one. I don't like the inelegant, brute-force
nature of it, either. All that said, I do think it would be
realistically possible, feasible, and perhaps even a bit sane, with
more than one person working on it. And once the main body of work is
completed, then it's on to 14.0, and once that is completely,
significantly less work would be required moving forward. until
$VERSION++, but that can be dealt with when it's reached.
So, all that said. There are a number of replies from people who would
like to see this happen. If there is anyone who would be interested in
forking the repo, then building a system to achieve this, please send
an email to me personally. In the end, all the work involved might be
easier.
J
Quoting J <j...@dawnrazor.net>:
Quoting Jan Herrygers <janherryg...@dommel.be>:
Op dinsdag 10 juli 2012 12:44:58 schreef J:
Thanks for clearing that up, I now see where you're coming from. And I
believe you're misunderstanding; please all me an attempt to clarify:
You want to build a tool that simplifies building a dependency graph. You
already stated that this "simplificating tool" shouldn't be and won't be a
replacement for reading the READme.
That's wrong and right - wrong about "want to", because I've already
done, but there are so many variations to the formatting - even
among those using the "This requires" format - that it's
increasingly non-trivial to handle... and as other emails in this
thread have indicated, I am not the only one who'd find this useful.
right about the rest, because it will only attempt to parse
requirements if the user has not chosen to skip viewing the README
file. otherwise, it will care about requirements exactly as the
slackbuild itself would have if the user were interacting with it
completely manually - ie not at all.
Let me think a little outside the box. Bear with me, or skip this section,
whatever you like.
I have read virtually ever word in this thread :)
Perhaps a tool, some variation of less, more, vim, Emacs, cat,... , can be
written in which you simply highlight the name of a dependency, and the text
that you highlighted is added to a dependency list.
When you are finished reading a readme, you move on to the readme
for the next
package on the dependency list. And so on ad infinitum (or until you have
finished your list).
That way you aren't dependent on any formatting being present, but you still
get a nice dependency tree. (I have no idea how one would build such a
program, but I'm optimistic about the feasability and feature set of the
mythical deptree tool I described above.)
This is a neat idea - but it still requires a parser. And once the
parsing is done, then it's a matter of actually running the
slackbuilds, so we're back to the doing the same exact manual steps
over and over and over again - and that's stupid, in my opinion.
personally, where I find myself doing the same manual steps over and
over, I automate. so, we have the parser, and we have the repeated
steps. ergo, my tool. it makes sense to me, anyway.
Op dinsdag 10 juli 2012 12:44:58 schreef J:
So, again: my concern is strictly limited to formatting, and only for
actual hard and fast requirements, not optionals. This represents a
minor formatting change *at worst*. And that, I believe, requires no
change to the testing currently done by admins.
Back in the box again.
A recommendation on how to list dependencies in a readme would be nice. But
asking the admins to either edit the recommended format into every
readme, or
to give you write access to the repo, is a lot to ask. I wouldn't count on a
standard that gets enforced to the point that it can be parsed with awk,
regexes, or something like that.
But publishing a recommendation doesn't hurt, and it can be
beneficial for the
human reader too.
I woul like a list delimited by newlines and/or tabs (perhaps multiple
spaces?) That would IMHO be much more readable than separated by
"," or "and"
delimiters.
Those who want to follow the recommendation, can do so, and those who don't
want to, can keep doing what it is that they do want to do.
not ideal of course, but this would be a start. couple things, then,
given this (not arguments, but discussion to possibly move it
forward):
1. how does such a recommendation get communicated to slackbuild
maintainers? admins out there, would you be willing to publish such
a recommendation on slackbuilds.org? after all, if it weren't stated
there, it wouldn't exactly be worth much.
2. formatting - newline/tab/multiple-space delimited, any of these
is easily parseable, so I would be happy with any of these options
or anything else that is easily parsed. but I do think it makes
sense to stick with the currently most popular format - otherwise we
end up with even more different types of formatting than we already
have.
off to work for me.
thanks.
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/
