[Slackbuilds-users] SlackBuild Ettiquette

[Christoph Willing]

Yes we know SlackBuilds have switches to set options. What I was 
referring to below was that these switches have default settings which 
shouldn't be arbitrarily manipulated.

At the first level, before those SlackBuild switches, an option's 
default is set by the upstream developers - a particular option might be 
set on or off but can be overridden when running the configure script 
with something like:
     --enable-xyz (or --disable-xyz)

At the second level are the options set by switches in the SlackBuilds - 
the one's you describe below. These are precisely the options we're 
already discussing; in particular what should these options default to?

As you probably know, the SlackBuilds themselves will contain (for the 
example you give below) something like:
     OPT1=${OPT1:-NO}
i.e. at this level, the maintainer has made "NO" the default, which the 
user must override at the command line with:
     OPT1=YES ./package.SlackBuild

What is (I believe) contentious is when the maintainer explicitly 
changes an option's default from what was set by the upstream 
developers. If OPT1 (whatever option it represents) would normally 
default to "on" if the configure script was run without explicitly 
setting it to on or off, then I don't think its right (in general) for 
the maintainer to impose a different default. In this case, the 
SlackBuild should say:
     OPT1=${OPT1:-YES}
and leave it to those users who don't want the option enabled to say:
     OPT1=NO ./package.SlackBuild

chris

On 11/13/2014 07:00 PM, Bojan Popovic wrote:
> Hi.
>
> Well that's why many SlackBuilds have optional switches. You can choose
> whatever you want from the command line
>
>   OPT1=YES OPT2=NO ./package.SlackBuild
>
> or in a sbopkg queuefile:
>
>   package | OPT1=YES OPT2=NO
>
> In there are optional switches, then it's not really important what
> defaults the maintainer chose.
>
> My 2,5 cents.
>
> Bojan.
>
> On Thu, 13 Nov 2014 14:13:22 +1000
> Christoph Willing <chris.willing at iinet.net.au> wrote:
>
>> For many softwares, optional features are either set or unset by
>> default in the configuration script supplied with the source code. In
>> accordance with the general Slackware practice of leaving upstream
>> alone as far as possible, I would suggest that the default values you
>> choose for options should be whatever are the defaults in the
>> software itself, _not_ what you happen to use yourself.
>>
>> Its quite annoying when SlackBuilds choose options contrary to the
>> upstream defaults. One SlackBuild that springs to mind immediately
>> turns off an option that is on by default just because the maintainer
>> himself doesn't use the facility provided by that option. Having it
>> turned on wouldn't force him to use the facility provided by the
>> option but he's actually added code to the SlackBuild to turn it off
>> anyway.
>>
>> chris
>>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>