[Slackbuilds-users] requirements in README files

[J]

Would you be so kind as to read a little further down? Perhaps the bit  
where I replied to Chess?

Quoting JK Wood <joshuakwood at gmail.com>:

> 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/
>>