[Slackbuilds-users] requirements in README files

[JK Wood]

On Jul 10, 2012 11:31 AM, "J" <j at dawnrazor.net> wrote:
>
>
> 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.

Maintainer of a number of scripts here. This has EVERYTHING to do with us.
You're asking me to take it upon myself to make a change that doesn't
benefit me, but benefits you? A change that allows you to go against the
philosophy that I subscribe to? Good luck, friend.

> 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
>
> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20120710/1385a904/attachment-0001.html>