[Slackbuilds-users] SlackBuild Ettiquette

[Christoph Willing]

For sure, options need tweaking occasionally; there are often good 
reasons (including public demand) for it. However I'm against changing 
them just to satisfy some personal world view of the maintainer e.g. 
"users of this package shouldn't build in the optional sudo plugin" (a 
completely contrived example).

I don't want to name names - the particular issue I'm thinking of was 
discussed briefly on this list already about six months ago and there's 
little point rehashing the same arguments. In all fairness, I should say 
that the maintainer offered to revert to vanilla if enough people 
wanted; I guess not enough people complained.

chris


On 11/13/2014 02:34 PM, Ivan Zaigralin wrote:
> I agree completely. However, in rare instances the options should or must be
> tweaked. Just look at the official firefox build, for example. In my case,
> I personally do NOT use the cited options, and I enabled them after much
> mulling over, after multiple users requested them. I think I could have
> been more cautious, but for what end? No one complained so far.
>
> I am curious, what is that package that "springs to mind"?
>
> On 11/12/2014 08:13 PM, Christoph Willing 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
>>
>>
>> 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/
>>>
>> _______________________________________________
>> 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/
>