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

[Andrzej Telszewski]

On 24/10/16 23:57, Christoph Willing wrote:
> On 25/10/16 01:37, Franzen wrote:
>> On 23.10.2016 12:36, Andrzej Telszewski wrote:
>>> On 23/10/16 01:56, Christoph Willing wrote:
>>>> Who is going to decide REQUIRED vs OPTIONAL for the many (I suspect)
>>>> non
>>>> obvious cases? Presumably the maintainer. If a maintainer's balance of
>>>> REQUIRED/OPTIONAL deps doesn't suit someone else's particular
>>>> needs/wants, then the builder will have to change their personal .info
>>>> files anyway (or complain to the maintainer).
>>>
>>> I think the problem of REQUIRED vs OPTIONAL has been solved long time
>>> ago.
>>> It's the maintainer that decides what is placed in REQUIRED and most
>>> probably 99% of us just installs what is there.
>>> And most probably 99% of the time what is placed in the REQUIRED is what
>>> is ABSOLUTELY necessary to compile the software or to run it (run time
>>> dependency).
>>>
>>> Everything else, i.e. things that could be added later on or are
>>> detected during compilation, are OPTIONAL.
>>>
>>> I'm the supporter of the OPTIONAL field and I actually proposed it
>>> sometime ago, but it was rejected too.
>>>
>>> I think there is too big resistance here for this addition, because
>>> naturally it would involve work.
>>
>> I think maintaining Options in README is about the same work as
>> providing an Options field in the Info-file.
>>
>> Looking at https://slackbuilds.org/repository/14.2/multimedia/ffmpeg/ ,
>> it felt much better to see this list in in an OPTIONAL field in, which
>> would also be parsable by tools like sbotools.
>>
> Because ffmpeg has so many options, it is a good example of the problem
> to decide which to include. Some people want a mean & lean ffmpeg with
> minimal options, while others want the lot. Even with a new OPTIONAL
> field, which options would be included in it that would please everyone?
> Each builder will probably modify to suit themselves.
>

The point is OPTIONAL wouldn't force you to do anything special.
It won't change the way you work, if you don't want to.

> Of course everyone already has that option - to modify the .info file
> with any additional fields they want. For ffmpeg I add:
>     ENVOPTS="LAME=yes X264=yes CELT=yes ..."
> My build tool finds ENVOPTS and exports each of the variables found,
> triggering the desired options already supplied in the ffmpeg.SlackBuild
> file.
>
> However the maintainer can't know what options I want. They could put
> all the possible options in a new OPTIONAL field but perhaps I don't
> want _all_ of them; just some of them. Then I, the builder, would still
> have to make the changes to suit my own needs/desires, so what has been
> gained?
>

Most probably what the supporters of OPTIONAL think of, is that this 
field would contain all the possible software that might be added to 
broaden the capabilities of the package, but is not absolutely necessary 
to compile/run the package.

Basically, it's all about moving/duplicating the information about 
optional packages from README to .info.

The OPTIONAL filed already exists, it's just in a format that is not 
possible to parse by machines. I.e. they cannot understand README ;-)

> Anyway, whatever the mechanism is used, its up to the various build
> tools to actually support it. Maybe one of the public build tools will
> introduce something of their own just to see if it catches on.
>

Exactly, it's for the build tools. They can store externally what 
optional packages have been chosen and work according to that.

> chris
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>

-- 
Best regards,
Andrzej Telszewski