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

David Disseldorp ddiss at
Mon Jul 20 15:01:42 UTC 2020

[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:
> 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 .

I don't feel strongly as to whether or not vfs_snapper should be built
by default.
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

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

Cheers, David

More information about the samba-technical mailing list