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
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
