PATCH: make disabling of vfs_snapper consistent with our configure/build system

[Karolin Seeger]

Hi,

Am 12.08.20 um 13:58 schrieb Björn JACKE via samba-technical:
> Hi,
> 
> On 2020-07-21 at 11:24 +1200 Andrew Bartlett via samba-technical sent off:
>> As to 'auto' options, my position, and one that I thought we had agreed
>> (it was written into BUILD_SYSTEMS.txt before that was removed, now in
>> the wscript and source3/wscript) is that Samba should require all
>> 'optional' libraries by default.
> 
> I'm not sure if I understand exactly what you mean here but for my
> understanding we should not require optional libraries by default: If a feature
> is enabled that requires a certain library it should be required of course.
> 
> The default values of configure feature flags has been a discussion with
> different opinions since a while. When we had the autotools build system we
> actually had almost(?) all feature configure options set to auto and we had
> a really great portability also on all the different unix flavours. Looking at
> portability, we're still suffering these days from the move to waf. I just
> mention this because the move to waf also was the point I think, where more and
> more features became not auto-enabled but enabled-by-default - no matter if
> those features exists or makes sense on the platform that we build on or not.
> Also the move away from the buildfarm to the autobuild made us focused on Linux
> only, which was probably another reason, why more features became
> enabled-by-default. We never had a consent on this though, it just happened
> silently.
> 
> 
>> The reason, as seen here, is that auto behaviour creates a difficult
>> issue for packagers.  Because packaging is a particular skill set, and
>> there are a lot of small distributions most of our packagers (with
>> exceptions of course) are not Samba experts.  The lack of a build
>> output (eg a .so) may be the only indication they get that a feature
>> has vanished when they package a new version of Samba.  
> 
> configure --help gives a list and packagers should (and usually do) use the
> --enable-foo configure flags to make sure that a wanted feature is actually
> enabled.
> 
> 
>> This is why auto-magic dependencies are a problem, even for non-
>> developer builds.
>>
>> This appears to be a broad concern, these reasons apply beyond just
>> Gentoo:
>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies
> 
> that site makes a distinction between automatic and automagic. The bad
> buildsystem thing that they call automagic, is when eatures cannot be
> explicitly enabled or disabled. But our "auto" is automatic and not automagic.
> 
> 
>> Furthermore, in the real world my recollection is that it has really
>> happened that the first this is noticed is when an end user finds their
>> package is using a workaround (eg lp* based printing vs CUPS) or is
>> missing a feature altogether.
> 
> I think if people compile their own samba version they are usually experienced
> enough to know what features they need to enable. Unexperienced users having
> compile issues with Samba are not really a good argument to enable all features
> by default. Did I say all features? Of course we do *not* enable all features
> by default only some, which is again an inconsistency.
> 
>> I realise that it is annoying for a individual systems administrator
>> who is building Samba, particularly on a non-linux platform, to have to
>> turn off many of our optional features first.  
> 
> indeed, it is. And the list of --disable-feature options that needs to be used
> there is continously growing. This is why I want to object to introduce more of
> those.
> 
> 
>> This is the reason we agreed that we would spit out an error as early
>> in the build, not just a late compile failure.  
> 
> as mentioned before, I don't think that we ever had a consent about the auto
> vs. enabled-by-default feature.
> 
> 
>> Thankfully the person in this situation is likely to understand what
>> they are disabling and know if it matters for their particular install.
>> Also, we know the vast bulk of Samba users get Samba via a distributor,
>> so anything to make this more fail-safe is, in my view, worth the
>> trade-off against the inconvenience of our manual builders.
> 
> I think auto need to be the default, package maintainers use the
> --enable-feature configure options.
> 
> If you really strongly think that something like this is needed, you might
> introduce a
> --enabled-all-supported-features-available-on-this-platform-by-default option.
> There is probably a nicer and shorter name for that but I wanted it to be
> descriptive here.
> 
> 
>> So, in this case, we certainly should make the behaviour consistent.  I
>> don't mind if it is --enable/--disable or otherwise, as long as it is
>> never 'auto', and the correct option to disable is listed in the error
>> text.
> 
> hm, setting them all to disable by default doesn't look like a nice idea
> either. I see really no problem with auto-enabling features. We did this all
> the years before and most software packages do it that way. For deveoper builds
> or autobuild runs we use already have hooks to set different defaults, for
> those builds we can also enable some more features by default that we want to
> test in any case.

this is currently a blocker for 4.13.0, so we need a solution asap. Can
we agree at least on a temporary workaround?
Or on shippting 4.13.0 anyway?

Cheers,
Karolin

-- 
Karolin Seeger			https://samba.org/~kseeger/
Release Manager Samba Team	https://samba.org
Team Lead Samba SerNet		https://sernet.de