<p dir="ltr"><br>
On Nov 30, 2015 4:44 AM, "Andrzej Telszewski" <<a href="mailto:atelszewski@gmail.com">atelszewski@gmail.com</a>> wrote:<br>
><br>
> On 30/11/15 11:13, Didier Spaier wrote:<br>
>><br>
>> On 30/11/2015 10:13, Andrzej Telszewski wrote:<br>
>>><br>
>>> On 30/11/15 00:31, Christoph Willing wrote:<br>
>>>><br>
>>>> On 11/30/2015 09:11 AM, Andrzej Telszewski wrote:<br>
>>>>><br>
>>>>> On 29/11/15 23:56, Christoph Willing wrote:<br>
>>>>>><br>
>>>>>> The only work is adding the options you want but that is also the<br>
>>>>>> advantage - you have the options _you_ want rather some some arbitrary<br>
>>>>>> set of options the maintainer wants or believes end users will want.<br>
>>>>><br>
>>>>><br>
>>>>> Actually, it's like that at the moment and it always will be like that.<br>
>>>>> I mean you will always have some choices that you can or not adjust to<br>
>>>>> your needs.<br>
>>>>><br>
>>>>> The difference is that "optional options" are mentioned in README,<br>
>>>>> whereas "required options" are placed in info - you put the optional<br>
>>>>> deps in *.info, which gives the whole thing better structure.<br>
>>>>><br>
>>>>> But it is always *YOU* who has to make the choice, the difference is how<br>
>>>>> the information about possible dependencies is given to you.<br>
>>>><br>
>>>><br>
>>>> We need to bear in mind the difference between options and dependencies.<br>
>>>> An added option may, or may not, entail an added build dependency i.e.<br>
>>>> any added ENVOPTS (or whatever) field _may_ need adjustment to the<br>
>>>> REQUIRED field too. In order to keep existing .info fields pristine, I<br>
>>>> use an additional PREREQS field to keep track of additional<br>
>>>> dependencies, leaving the REQUIRED field intact.<br>
>>><br>
>>><br>
>>> I think we understand each other, it's just wording that's awkward.<br>
>>><br>
>>> I would see it more less (without longer thinking) like that:<br>
>>> - additional file for optional dependencies, together with the<br>
>>> environment variable (if applicable),<br>
>>> - additional file for environment variables that do not require software<br>
>>> dependency.<br>
>>><br>
>>> That would require at least 2 things:<br>
>>> - forcing SlackBuild-s creators to use the particular structure - that's<br>
>>> not a problem, because SBo already has some requirements,<br>
>><br>
>> Good luck to get that done, but do not hold your breath.<br>
>><br>
>>> - making the website processing additional information to display it to<br>
>>> the user; it's important, because it would be error prone to expect the<br>
>>> SlackBuild creator to maintain README and additional meta-data files in<br>
>>> sync.<br>
>><br>
>> I will let the website maintainers and admins answer that.<br>
>><br>
>> I am reluctant.<br>
>> _ If a dependency is optional it's up to a human being to take or refuse it.<br>
>> _ We have already a lot of (I almost wrote "too many") package managers, as<br>
>> listed by David (thanks again for the list):<br>
>> <a href="http://idlemoor.github.io/slackrepo/links.html">http://idlemoor.github.io/slackrepo/links.html</a><br>
>> It would take a lot of time to modify all of them accordingly.<br>
>> _ Along the time package managers naturally tend to provide more and more<br>
>> features less and less useful, that just complicate their usage and<br>
>> sometimes introduce bugs.<br>
>> _ Some features, although they be useful, exist since a long time and come<br>
>> handy, are probably not used by many folks, like editing a SlackBuild or<br>
>> a .info from sbopkg. The more features, the more time needed by end users<br>
>> to use them.<br>
>> _ It is not that difficult to list optional dependencies in a SlackBuild<br>
>> if the target audience is human beings, not computer propgrams.<br>
>> This is just an example:<br>
>> <a href="http://slackbuilds.org/repository/14.1/misc/po4a/">http://slackbuilds.org/repository/14.1/misc/po4a/</a><br>
>><br>
>>> Still, is it worth?<br>
>><br>
>> No, IMHO.<br>
><br>
><br>
> Well, I too think that it would be much work, it's probably not worth it.<br>
><br>
> What is your opinion on the READMEs? For me it was the culprit, that made me propose what I've proposed. It's my personal opinion, but the READMEs are not well readable;)<br>
><br>
> I would propose to allow markdown in READMEs, but still, the maintainers would have to use it in consistent way.<br>
><br>
> I know one should read the READMEs thoroughly, but it's much easier to spot what's important, if it's *for example in bold*.<br>
><br>
> Like any other well written software, SBo deserves good documentation:)<br>
><br>
> I don't think we'll go much further with that for a moment;)<br>
><br>
><br>
>><br>
>> I hope that this negative answer will not discourage you. We do need folks<br>
>> to make proposals, be they accepted or not, so thanks for this one Andrzej.<br>
><br>
><br>
> No worries:)<br>
><br>
><br>
>><br>
>> Bien cordialement.<br>
>> Best regards,<br>
>> Pozdrawiam.<br>
><br>
><br>
> Saludos cordiales:)<br>
><br>
><br>
>><br>
>> Didier<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>
>><br>
><br>
><br>
> -- <br>
> Pozdrawiam,<br>
> Best regards,<br>
> Andrzej Telszewski<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>
></p>
<p dir="ltr">READMEs are meant to be human readable, not to be machine readable. Further, we expect them to not only be human readable, but also to actually be read by humans. Markdown is fine for the web, but I read package READMEs in vim on the command line - markdown would make that quite a bit messier.</p>
<p dir="ltr">We have few enough maintainers as it is. I provide my SlackBuilds free of charge, without compensation, and on my own time. My intention is to provide a good starting point from which to build and package a piece of software. Advanced usage is up to the end user, and the onus should not be on me to make it easier for some automated tool to facilitate that advanced usage. I have enough problems from the software I package alone without having more demands made on my time for very little benefit.</p>
<p dir="ltr">If you have an issue with a particular README from a particular SlackBuild, a more productive approach would be to email that maintainer rather than defaulting to suggesting there's a systemic problem with the way we do things on the public mailing list.</p>
<p dir="ltr">--JK</p>