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

[David Disseldorp]

[sorry about the late response. I just returned from vacation]

Hi Ralph and Björn,

On Mon, 13 Jul 2020 18:48:50 +0200, Ralph Boehme via samba-technical wrote:

> Hi all!
> 
> Am 7/10/20 um 9:44 PM schrieb Björn JACKE:
> > On 2020-07-10 at 20:31 +0200 Stefan Metzmacher via samba-technical sent off:  
> >> I don't see why your change would be needed, I actually think it makes
> >> the situation worse, as --disable-snapper is no longer available  
> > 
> > I tried to descibe that in the bug report. Our correct way to disable shared
> > modules is to use --with-shared-modules='!module_name'.  That mechanism gets
> > broken by 7ae03a19b3ca895ba5f97a6bd4f9539d8daa6e0a. So the new option
> > introduced by 7ae03a19b3ca895ba5f97a6bd4f9539d8daa6e0a is not needed and it
> > makes our generic mechanism to disable the shared module stop working.
> >   
> >> and configure would just fail if dbus-1 is not available.  
> > 
> > that's what it currently also does. This is because in the discussion it was
> > desired that this should be a forced enabled feature by default. Personally I
> > would prefer forced-enabled features for developer builds if this is meant to
> > detect failrures in autobuild. But that's another discussion. In any case
> > configure fails (intentionally) with 7ae03a19b3ca895ba5f97a6bd4f9539d8daa6e0a
> > and without 7ae03a19b3ca895ba5f97a6bd4f9539d8daa6e0a by default if dbus-1 is
> > unavailable.  
> 
> of, what a mess! :)
> 
> Currently the snapper configure check is the only one of the three
> (snapper, cephfs, glusterfs) VFS module configure options that implement
> --enable-NAME=yes "correctly" (as per --enable-XXX configure semantics).
> 
> The other ones (ceph, glusterfs) will just silently pass if a dependency
> is missing, effectively implementing default="auto" behaviour.
> 
> I don't think we want all of those modules to fail with a
> default="true", that would result in too much configure churn while
> user's configure runs fail one after the other, forcing them to add
> --disable-XXX to the configure invocation.
> 
> I guess we should just default to "auto" for all three modules.
> 
> Here's a MR that implements this:
> 
> https://gitlab.com/samba-team/samba/-/merge_requests/1461
> 
> If we decide that we really want all three modules to use and enforce a
> default value of "true", this can be achieved by merely switching the
> defaults in the above MR.
> 
> Thoughts?

When discussing 7ae03a19b3ca895ba5f97a6bd4f9539d8daa6e0a, Andrew and I
both agreed that "auto" behaviour is undesirable, as it leads to the
kinds of inconsistent build results carried in Matt's initial report
at https://bugs.gentoo.org/721320 .

I don't feel strongly as to whether or not vfs_snapper should be built
by default. https://gitlab.com/samba-team/samba/-/merge_requests/1335
eventually saw it enabled by default, with clear documentation on how
it can be disabled at configured time.

Given that Björn's initial complaint was with the inconsistent / broken
--with-shared-modules='!module_name' behaviour, would it be okay if we
just fix --with-shared-modules='!vfs_snapper' and drop
--enable/disable-snapper?

Either way, it'd be nice to wait for Andrew's input here too.

Cheers, David