[Slackbuilds-users] requirements in README files

[J]

Well, morning folks. why is it always morning when one works  
nightshift? so not fair. anyway.

so, first off, sbotools already exists and has some  
requirement-parsing, it is how I deal with slackbuilds.org myself. and  
I continue to hack on the parsing code to improve it for the gazillion  
corner-cases.

so let's talk about some of the irrelevancies that keep cropping up  
for a moment, so that we can hopefully stop talking about them, stop  
all this bikeshedding, and focus on the subject at hand.

1. portage - I don't think anyone here has any interest in duplicating  
that mess. I certainly don't.
2. the "slackware way" - if you feel that manually dealing with your   
sbo requirements keep you true and pure to the "way" - fine, so what,  
and who cares? this has nothing to do with you, so please stop  
bikeshedding.
3. Buildtime, optional, etc - I talked about this already. I am only  
interested in consistency about how hard and fast requirements are  
documented in README files, and that is *it*. I am not interested in  
changing anything else, anywhere, including how optional dependencies  
are or are not documented.
4. sbopkg and queue files - that idea is cool, but as a solution to  
this problem it represents not only a massive repeating of work, but  
also a massive amount of extremely inelegant brute-forcing.

I've seen a few times mention of adding this stuff to the SlackBuild,  
or a separate file. As I mentioned, that would be ideal - it is by the  
far the easiest solution to handle programatically. but it doesn't  
make sense here, and I personally am not terribly interested in seeing  
this happen. requirements *must* be listed in the README - so, since  
they're there already, that will do, if we can get some consistency.  
With that, then in the following case:

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

> specify the build depenednecies but over the last year or so I have  
> been modifying SBo scripts (when they already exist) to include a  
> PREREQS= line in the info file. If PREREQS were already included, I  
> wouldn't have to maintain my own versions of them. However the  
> effort in doing so is worth it, so I do.

Christoph could easily write his own parser to deal with his use-case.

anyway.

Quoting TuxaneMedia <jens at tuxane.com>:

> The admins do alter README files and it looks like this is getting the
> way to go:
>
> "This requires zope.component and gaphas "

is this absolute fact? can we get some admins to chime in? if this is  
fact, and all admins are doing it and following the same format, then  
this means that for 14.0 we'll have consistency, and my work here is  
done.

Quoting Chess Griffin <chess at chessgriffin.com>:

> Finally, and here is where I put on my "former SBo admin" hat on, if the
> SBo project were to change things and start requiring that build-time
> dependencies be included in the README or .info file, then this would
> definitely lead to more work for the current SBo admins, who already put
> in a lot of time in maintaining SBo.  The fact is that many SlackBuild
> script maintainers are not that communicative (and I've been guilty of
> this myself -- I only just now got to updating OpenArena after /many/
> requests -- sorry!) and either the admins would have to try and track
> down all the maintainers to update their submissions to the new format
> or do it themselves.  And, of course, test the listed dependencies.
> What if someone forgot to add a dependency?  Each submission would have
> to be tested on a clean, newly installed system in a VM or something to
> ensure that the dependencies were listed correctly and in the right
> order.  That's a lot of work.

I think this is both true and false. regarding the work load, you're  
absolutely right, and I would be absolutely *delighted* to handle the  
format-ensuring stuff. where you're dead wrong is the stuff about  
testing. what in the world does all that have to do with anything? the  
testing process wouldn't change one iota from where it currently stands.

well, thanks to the folks who've made intelligent and well-thought out  
points on both sides. hopefully we can get some maintainers to weight  
in now. maintainers?

thanks folks.
J