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

[King Beowulf]

On 10/24/2016 02:57 PM, Christoph Willing wrote:
>>-----
>>
> Because ffmpeg has so many options, it is a good example of the problem
> to decide which to include. Some people want a mean & lean ffmpeg with
> minimal options, while others want the lot. Even with a new OPTIONAL
> field, which options would be included in it that would please everyone?
> Each builder will probably modify to suit themselves.
> 
> Of course everyone already has that option - to modify the .info file
> with any additional fields they want. For ffmpeg I add:
>     ENVOPTS="LAME=yes X264=yes CELT=yes ..."
> My build tool finds ENVOPTS and exports each of the variables found,
> triggering the desired options already supplied in the ffmpeg.SlackBuild
> file.
> 
> However the maintainer can't know what options I want. They could put
> all the possible options in a new OPTIONAL field but perhaps I don't
> want _all_ of them; just some of them. Then I, the builder, would still
> have to make the changes to suit my own needs/desires, so what has been
> gained?
> 
> Anyway, whatever the mechanism is used, its up to the various build
> tools to actually support it. Maybe one of the public build tools will
> introduce something of their own just to see if it catches on.
> 
> chris
> 
<start of RANT>

Reading through this threads commentary, I find everyone is going in
circles.  The above is one of the smarter responses.

Whether it's ffmpeg, qemu or whatever there are just too many optional
choices.  Debian et al., Redhat, Gentoo, etc all try to automate the
software installation process with mixed results.

[
Day1:
Gentoo User: "Yo Ed, check out "emerge world"! How cool is that?"
Day 2:
Me: "Say, is your server still up?"
Gentoo: "In a bit. I decided to reinstall from scratch."
Me: "What happened?"
Gentoo: "Oh, just decided to start over clean."
Me: (Sigh).
]

20+ yrs ago I choose Slackware because WE DON"T DO THAT.

SBo, has a difficult task: It's one thing to test for all REQUIRED deps
so that a package compiles, it's quite another to sift though the
various build systems (Documentation? Read the source, Luke.) to find
various optional deps. I've run into
1. Autodetected at compile time
2. Autodetected at run time
3. Configured during compile time but not autodetected
There can be SCORES of these in various combinations, even after
adjusting for a full Slackware installation. Some even have x86_64 vs
x86 choices. This is just nuts from an automation standpoint.

As Chris states above, not everyone will want the same options.  Thus
there is no way to keep everyone happy.  As a maintainer, I volunteer my
time on SBo and LQ to "pay forward" for all those years a sucked for
free off the Slackware teat.  I also purchase the odd item at the
Slackware Store. That is pretty much my total skill set available.

I personally use most of the SBo scripts I maintain. I simply do not
have the time, the skill, or the hardware to sift and test all OPTIONAL
deps.  Hell, I don't even work in the Computer software/hardware/MIS/IT
industry. As far as I know, no one involved in SBo gets paid.

So, I vote NO on additional bloat added to SBo.  Additional functions
should have a damn good reason to exist, simple to implement, easy to
maintain, and transparent.

For those who disagree I think I should devote my time to making their
lives easier, I suggest you fork the repo and do whatever the hell you
want. Just stop nagging me for weird-ass option most people don't use.
I have yet to nag an SBo maintainer of a scrip I use to add optional
support that may only be useful to me.

Now that said, I will be adding BRIDGE_HELPER_SETUID to qemu, for
example, because
1. I didn't now about it
2. it's useful to the entire user base
I am not opposed to having the community emailing me with useful feature
additions or true bug reports.  I just thinks it is up to the individual
user to add their own fringe-case options.

-Ed
<end of RANT>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20161105/3f85f446/attachment.asc>