[Slackbuilds-users] SlackBuild Ettiquette

Christoph Willing chris.willing at iinet.net.au
Thu Nov 13 04:13:22 UTC 2014


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


On 11/13/2014 01:25 PM, Ivan Zaigralin wrote:
> Agreed. For example, I did this in R SlackBuild:
>
> if [ "${R_SHLIB:-yes}" = "yes" ]; then
>    r_shlib="--enable-R-shlib"
> else
>    r_shlib="--disable-R-shlib"
> fi
> if [ "${BLAS_SHLIB:-yes}" = "yes" ]; then
>    blas_shlib="--enable-BLAS-shlib"
> else
>    blas_shlib="--disable-BLAS-shlib"
> fi
>
> and then passed these to configure. I opted to enable them by default
> after I spoke with R devs and was told that literally nothing can go
> wrong, and the performance impact is negligible for most practical
> purposes. How to set the default values is entirely up to you as a
> maintainer, but I would pay attention to what your users want, as well
> as KISS.
>
> On 11/12/2014 07:16 PM, King Beowulf wrote:
>> On Wednesday, November 12, 2014, Barry Grundy <bgrundy at gmail.com
>> <mailto:bgrundy at gmail.com>> wrote:
>>
>>      I maintain a particular package, and it's due for an upgrade.  I've been
>>      playing with one of the options to the package and Iv'e determined that for
>>      my use I would rarely run without that particular option.
>>
>>      Is it bad practice to have the SlackBuild enable an option by default?
>>      Obviously the README would cover the subject.  Basically I'm asking to turn
>>      an option into a "requirement". Â
>>
>>      The package in question is bulk_extractor (already in SBo), and the option
>>      is liblightgrep (I'll be submitting the new SlackBuild concurrently).
>>
>>      The .info would reflect the requirement, and the bulk_extractor README would
>>      indicate that the requirement could be disabled by removing
>>      "--enable-liblightgrep" from the SlackBuild. Â
>>
>>      Is this kosher(ish)?
>>
>>
>> Why not set up a switch, on/off by default, say, so that the option can be
>> run/not run without editing the script:
>>
>> LLG=yes ./blah.SlackBuild
>>
>> This is done in a number of scripts (JDK, qemu, nvidia, ...)
>>
>> Â
>>
>>
>> --
>> You! What PLANET is this!
>> Â  Â  -- McCoy, "The City on the Edge of Forever", stardate 3134.0
>>
>>
>>
>> _______________________________________________
>> 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/
>>
>
>
>
> _______________________________________________
> 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/
>


More information about the SlackBuilds-users mailing list