[Libguestfs] distributing bash completion links [was: [libnbd PATCH 17/20] ci: Add support for test skipping]

[Eric Blake]

On Tue, Jun 08, 2021 at 09:09:32PM +0200, Martin Kletzander wrote:
> I still have one more thing that bothers me, though.  The symlinks in
> bash/ are set to be generated and packed into the distribution (using
> the `dist_` prefix for `dist_bashcompdir_DATA`), but they are defined
> conditionally based on whether bash-completion (and libxml2) are
> available on the system.  This, of course, breaks `make dist` for
> systems where any of the packages is not available.  I think that there
> are few ways how to get out of it:

Yeah, it's never a good idea to have the contents of a tarball differ
according to what was present on the machine of the person running
'make dist'.  Tarballs should be invariant, such that what gets
installed should be determined solely by the results of ./configure on
the machine unpacking the tarball, not on the machine that created the
tarball.  So you have indeed uncovered a bug that needs fixing.

> 
> 1) Remove the `dist_` prefix -- this would generate the files during
>    build time when the availability of the dependencies is more relevant.

That means the files only get installed on platforms where configure
says it is useful to install them, rather than being part of the
tarball.  Seems reasonable.

> 
> 2) Remove the conditionals -- creating the files only relies only on
>    `ln` to create the symlink so there is no need for the dependency to
>    be available.

That says the files should always be part of the tarball, regardless
of whether they will be installed.  Also seems reasonable.

> 
> 3) Remove the rules and commit the symlinks to the repository -- this
>    would keep the symlinks in git, they would get installed based on the
>    conditionals, but would be always available for packing into the
>    distribution, at least that's how I understand automake.

The autotools frown on shipping a tarball with a symlink (because not
all systems support symlinks, so extracting such a tarball is not
portable).  That recommendation still exists today, where the major
culprits are Windows and FAT filesystems.  Windows actually supports
symlinks on NTFS file systems, but not necessarily out-of-the-box, but
more importantly, anyone who unpacks the tarball on a flash drive
(which are most-often formatted as FAT) suffer from the problem.  So
just as we shouldn't stick symlinks in the tarball (but instead should
generate them during './config.status'), we probably shouldn't need to
store symlinks in git.

Of all of these options, I'm leaning the most towards 1.  But it's not
at the top of my priority list at the moment, so I suspect it will be
easier for you to propose a patch and me review it than for me to try
and write the patch.

Thanks for working on CI, by the way!

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org