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

[Björn JACKE]

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.

Björn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20200812/b6da2855/signature.sig>