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

[Erik Hanson]

On Sat, 5 Nov 2016 21:59:11 +0100
Andrzej Telszewski <atelszewski at gmail.com> wrote:

> On 05/11/16 21:44, Erik Hanson wrote:
> > 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 for one would be pleased by the tool that presents the optional 
> packages, allowing me to just select those I want.

I'm not sure if this statement is for or against what I said, such is
the nature of text-based communication. All I can add is that I believe
it would be very important for said tool to provide that context. Can
we expect all 3rd party tools to adopt a policy to inform their users
in some way? I don't think so.

Why is that important? Well, the tools that don't inform the user open
things up to people just hitting "Yes" on all the optional deps. I
mean, why wouldn't you want the most functionality built in to your
packages? 

I can only envision the bug reports we would get, the same way the vast
majority of bug reports currently come in with sbopkg text at the end.
We don't endorse or support sbopkg, yet there it is.

Next up, bug reports of 'fails to compile' or 'package broken' or
'trashed my system', none of which we can really deal with. All the
result of some tool saying 'tick the boxes of what you want' - all
context stripped away. People still need to read the README.

> You kinda have point with the context of the deps, but we're not here
> to babysit people. One shall README, period.

And there is the crux of the entire matter. Currently, we expect people
to read the README. A machine-readable field of optional deps means
people have even less reason to read the README. Nothing good comes of
this. A few power users might be okay, but the other 99.9% of people:
fucked. Our goal has always been a repo of scripts that reliably create
valid packages. OPTIONAL provides too many ways for that to go wrong.

Read the README and you're golden. 


-- 
Erik