3:54 a.m.
On Wed, Jun 09, 2021 at 06:17:39PM +0100, Richard W.M. Jones wrote:
On Wed, Jun 09, 2021 at 11:00:26AM -0500, Eric Blake wrote:
> 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.
I've been gradually fixing similar issues over time, eg most recently:
https://gitlab.com/nbdkit/nbdkit/-/commit/021f44bfed9b222677c90402486bec7...
So yes, I agree with what Eric said.
Rich.
> >
> > 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.
>
I'll replace the "skip make dist on opensuse" with this patch in the
next version. Thanks for confirming what I thought.
> 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
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/