<p><br>
On Jul 10, 2012 11:31 AM, "J" <<a href="mailto:j@dawnrazor.net">j@dawnrazor.net</a>> wrote:<br>
><br>
><br>
> Well, morning folks. why is it always morning when one works nightshift? so not fair. anyway.<br>
><br>
> so, first off, sbotools already exists and has some requirement-parsing, it is how I deal with <a href="http://slackbuilds.org">slackbuilds.org</a> myself. and I continue to hack on the parsing code to improve it for the gazillion corner-cases.<br>

><br>
> 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.<br>
><br>
> 1. portage - I don't think anyone here has any interest in duplicating that mess. I certainly don't.<br>
> 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.</p>

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

<p>> 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.<br>

> 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.<br>
><br>
> 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:<br>

><br>
><br>
> Quoting Christoph Willing <<a href="mailto:c.willing@uq.edu.au">c.willing@uq.edu.au</a>>:<br>
><br>
>> 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.<br>

><br>
><br>
> Christoph could easily write his own parser to deal with his use-case.<br>
><br>
> anyway.<br>
><br>
><br>
> Quoting TuxaneMedia <<a href="mailto:jens@tuxane.com">jens@tuxane.com</a>>:<br>
><br>
>> The admins do alter README files and it looks like this is getting the<br>
>> way to go:<br>
>><br>
>> "This requires zope.component and gaphas "<br>
><br>
><br>
> 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.<br>

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

><br>
> 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?<br>
><br>
> thanks folks.<br>
><br>
> J<br>
><br>
> _______________________________________________<br>
> SlackBuilds-users mailing list<br>
> <a href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.org</a><br>
> <a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
> Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
> FAQ - <a href="http://slackbuilds.org/faq/">http://slackbuilds.org/faq/</a><br>
><br>
</p>