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

[Franzen]

> In my opinion,
> real life is much too complex for OPTIONAL=

I feel it's too much hassle without that field, at least for an enduser.

The OPTION field
  -should NOT replace the README.
  -is not meant to be complex to force a debian-apt-like engine, which 
wants to cover every case and will therefore fail.
  -is meant to cover the OPTIONS which are already present in 
BuildScripts, and that bin a better way, not more.

In my ideal world:
-On https://slackbuilds.org render content of slack-desc(instead of 
README) + REQUIRED + OPTIONAL (like Kyle proposed, if understood him 
right)
-Leave README as is(clickable as all package-content)
-Mandatory OPTIONAL-field in the .info-file for new submussion

> Look at this example (graphics/luminance-hdr)
> 
>> The following are optional dependencies:
>> cfitsio and CCfits - for importing FITS images (both needed)
>> hugin              - for aligning multiple LDR exposures

REQUIRES="qt5-webkit"
OPTIONAL="hugin,cfitsio & CCfits"

> And this example (gis/gdal):
> 
>> The following optional requirements are detected automatically:
>> cfitsio, freexl, hdf, hdf5, libwebp, netcdf, postgresql, xerces-c
>> 
>> To enable OpenCL GPU-accelerated performance, specify the option
>> OPENCL=yes (requires opencl-headers to build, and either nvidia-driver
>> or amd-app-sdk with suitable GPU hardware to run).

REQUIRES="geos,proj"
OPTIONAL="opencl-headers:(nvidia-driver|amd-app-sdk),
cfitsio,freexl,hdf,hdf5,libwebp,netcdf,postgresql,xerces-c"

Easy enough in my opinion, also easy&fast to understand if one is not a 
native english speaker.

> Users need to know what useful features each dep provides, if that
> information is available upstream.
> Some users want to know if deps are build-time only, or run-time only.
> Users need to know whether deps are automatically detected, or whether
> there are environment variables that need to be set.

This is also not completely covered in all READMEs the current state,
and doesn't get worse if there would be an OPTION-field also.

> (Not all
> SlackBuilds use environment variables in the same way, and some
> SlackBuilds would need to be rewritten if we standardised on (for
> example) OPTIONAL="libass:ASS=yes|no libbluray:BLURAY=yes|no".  Who's
> going to find them all? Who's going to fix them all?  Who's going to
> change all the users' queue files and build scripts?)

I volonteer to help. If the OPTIONAL-field is added to all SlackBuilds 
nothing will break if it's empty at first. Every SBo-submission would 
also help in parallel.

> And some users (ok, me) don't like XML, and don't like YAML, and don't
> like new stuff such as "[opt]libass[/opt]"
> parser for from scratch when XML and YAML already exist, and don't
> like reading stuff that's complicated. I don't think anybody -- either
> maintainers or users -- would enjoy having half the README file or the
> .info file written in YAML, but that's the kind of thing that would be
> needed if you look at all the real examples in SBo.

No YAML or XML needed to be written, just a simple syntax as proposed.

> IMO it's best to read all ~5800 README files before thinking about a
> solution.

Is that really your proposal for all slackware-maintainers, or for all 
SBo-users?
I'll get divorced from my wife, if i do that ;-)

Johannes