[Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]
elyk03 at gmail.com
Sat Nov 5 03:51:37 UTC 2016
On 11/4/16, David Spencer <baildon.research at googlemail.com> wrote:
> Hi - let me say to start that this is only a personal opinion, and
> I've been too busy recently to pay careful attention to this
> discussion. But IIRC we've talked about this before. In my opinion,
> real life is much too complex for OPTIONAL=
> 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
> 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).
> Users need to know what useful features each dep provides, if that
> information is available upstream.
> Users need to know if some deps are needed together (like cfitsio and
> CCfits above), or if some deps are mutually exclusive (like
> nvidia-driver and amd-app-sdk above).
> 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. (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?)
> 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]" that I'd have to write a
> 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.
> IMO it's best to read all ~5800 README files before thinking about a
> solution. I've done it. It's quite easy to spot the interesting ones
> if you step through them quickly.
I like the idea of having an OPTIONAL field because it could allow us
to have clickable links on the website, and you could use it to build
a better dependency graph. So for example if I'm updating a library
and want to know what packages might be using it, searching through
both REQUIRES and OPTIONAL could turn up a lot more hits than REQUIRES
alone. It'd also be much more accurate than searching through README.
I'm not a fan of putting script parameters in OPTIONAL, I think that
would turn into a mess in a hurry. Better to keep that info in the
README, and just keep OPTIONAL as a list of packages just like
REQUIRES. Basically if any optional package is mentioned in the
README, also put it in OPTIONAL just to establish a link between the
This is somewhat off-topic, but I remember discussions in the past
that the file is called README because you need to read it. But I'm
sure we're all guilty of not reading it at some point. I usually
don't, thinking that it just contains the package description, and if
I'm installing it I already have an idea of what it does and why I
need it. Then I realize there may be installation information I'm
missing, so I go back and read it.
What do you think about splitting off the package description into its
own file (named "ABOUT" or somesuch)? ABOUT would contain the
description (maybe just a repeat of slack-desc, or something longer
and more detailed). README would contain package conflicts, more info
about optional dependencies and what they would provide, script
variables, pre-build or post-build instructions, etc. The README file
itself would be optional in case there are no extra instructions, but
if it exists you should read it! Each package should contain at least
one of the two files, the website would show both, and descriptions
could slowly be migrated to the ABOUT file at the maintainer's
leisure. Any opinions?
More information about the SlackBuilds-users