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

Erik Hanson erik at slackbuilds.org
Sat Nov 5 20:44:58 UTC 2016

On Fri, 4 Nov 2016 18:25:32 +0000
David Spencer <baildon.research at googlemail.com> wrote:

> 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?)

What I also don't see much (any?) mention of is what the admins will
have to refactor.. the website, php, database, internal tools we use
for submission/approval process (there are many) .. things are more
complicated behind the scenes than people realize. It's a messy and
time-consuming job. Adding an OPTIONAL field to the info file isn't
something that, if only someone would do it, magically "just works".

Forgetting the above (clickable links on the website, etc.) it's still
not as simple as duplicating some of the README into the info file. The
README file also contains maintainer commentary on what those optional
deps provide, why someone may or may not want them, etc. Sometimes,
those deps don't even exist on SBo, require system changes outside
package management, increase compile time providing no benefit, and so
on. It's not a good idea to present users with a simple list of
optional deps without context. People still need to read the README.

I get that what people want is a feature request, and not a solution to
a problem. The issue I have is that this feature boils down to "I'd
like to skip reading the README files please", and that's not a request
that should be entertained, in my opinion.

I'm not necessarily against an OPTIONAL field, since I quite like the
way AUR works, for example. It's just really difficult to implement
here. Theory crafting a grand syntax, and other ideas, are certainly
fun exercises, but are very far removed from the real problems this
additional field presents if implemented.

> 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.

What my own custom build tool does is display the README and prompt
"Continue building Y/n?" - As a founder of SBo, I'm about as seasoned as
it gets when it comes to using the repo, and I still find this to be an
invaluable step. If only the 3rd party tools made available to the
public did the same...


More information about the SlackBuilds-users mailing list