[Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Andrzej Telszewski]

On 07/11/16 12:35, Andreas Guldstrand wrote:
> Another thread proposed allowing markdown-like sections in the READMEs
> and standardising on how to format the README for each slackbuild
> according to that, which would be fine IMO as it's still very readable
> in a text editor; the markdown section tagging is very easy to read.
>

I don't like anything else than pure text going into README, markdown is 
no different.
Yet I would agree on that and my eyes would have to get used to it :-)

> But adding semantics for individual env options and optional
> dependencies in the README strikes me as a horrible idea. Not only
> would it be absolute hell for any machine to parse and be extremely
> prone to syntax errors from the author (it's a README! SYNTAX
> ERRORS????), but it would also look like utter s**te in a text editor.
>

The syntax I proposed, was just proposal.
Maybe someone can come up with something much better and cleaner.
And the syntax would be checked at submission time.

> On 7 November 2016 at 12:14, Andrzej Telszewski <atelszewski at gmail.com> wrote:
>> Hi,
>>
>> I haven't slept too long and came up with the following idea
>> (this assumes that we do *somehow* agree on some tags in README):
>>
>>
>> The following optional, not auto-detected packages enable additional
>> features (you need to install the package and set environment variable):
>>
>> [opt] libass, [env] ASS=yes|no [/opt], for ASS support,
>> [opt] libbluray, [env] BLURAY=yes|no [/opt], for BLURAY support,
>> [opt] libiec61883, libavc1394, [env] IEC61883=yes|no [/opt], for IEC61883
>> support,
>>
>>
>> The magic behind:
>> we do not modify .info in any way, we just allow willing maintainers (you
>> can choose if you want or not to support the idea) to structure the README
>> in particular way, enclosing optional packages and environment variables in
>> tags.
>>
>> We do it only for simple cases, i.e. if there is dependency that requires
>> choosing between two exclusive ones, of which one depends on another
>> optional package, then we leave it to human for parsing (although it still
>> would be very helpful to be able to click on the optional package to see
>> what is it about).
>>
>> SBo would parse the README to create clickable optional packages.
>> Build tools would do what they have to do to do what they want to do.
>>
>> SBo would allow for README preview, so the maintainer could ensure it's the
>> way he thinks it is.
>> SBo would immediately reject the submission if there was syntax error (yuk,
>> syntax error in README :-^).
>>
>> Subject for improvements :-)
>>

-- 
Best regards,
Andrzej Telszewski