GNU bug report logs - #10878
"make dist" with read-only srcdir generates read-only tarball

Previous Next

Full log

Message #47 received at 10878 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: 10878 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	automake-patches <at> gnu.org
Subject: Re: bug#10878: "make dist" with read-only srcdir generates read-only
	tarball
Date: Fri, 24 Feb 2012 20:48:13 +0100

On 02/24/2012 08:34 PM, Nick Bowler wrote:
>
> On 2012-02-24 12:10 -0700, Eric Blake wrote:
>
> [BIG SNIP]
>
>> Which is _why_ 'make distcheck' intentionally checks that 'make dist'
>> from a read-only source tarball will accurately create a tarball.
> 
> It checks that it creates a tarball, but as I mentioned in another
> paragraph (which you elided), it does not check that the tarball is
> accurate.
>
Well, it tries at least, by checking common symptoms for inaccuracy
(failure to build with a read-only source tree, "make distclean"
leaving files in the build tree, "make dist" failing from an
extracted tarball, ...).  Of course, it cannot be perfect, and
there are tons of subtle potential breakages it won't catch; but
IMHO it does a good work overall.

> In my original example, "make distcheck" failed to notice that
> the generated tarball was wrong: i.e., it was not the same as the
> original tarball it was testing.
>
How so?  Honest question, that doesn't seem clear from your
descriptions and explanations so far.

>> This is a _feature_ of automake's 'make distcheck'.  If you want to
>> guarantee that the generated tarball has certain permissions, then
>> you, as the package author, must add something in your dist-hook to
>> guarantee it, since automake cannot know which files you _need_ to
>> leave writable.
> 
> The answer is: all of them!
>
In light of our discussion so far, implementing this would seems like
a gratuitous modification to me.  Let me explain why.  Both the existing
behaviour and the one you propose are non-broken and have their merits,
and both would be quite easy to implement on a per-project basis if the
other behaviour were the default.  Given this consideration, for the
sake of simplicity and backward-compatibility, I simply prefer to leave
the pre-existing behaviour in place.

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.