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

Martin Kletzander mkletzan at redhat.com
Thu Jun 10 08:54:38 UTC 2021


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/021f44bfed9b222677c90402486bec76c16a1ef3
>
>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/
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20210610/c1b6c133/attachment.sig>


More information about the Libguestfs mailing list