[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#10878: "make dist" with read-only srcdir generates read-only tar

From: Stefano Lattarini
Subject: Re: bug#10878: "make dist" with read-only srcdir generates read-only tarball
Date: Fri, 24 Feb 2012 19:19:32 +0100

On 02/24/2012 06:53 PM, Nick Bowler wrote:
> On 2012-02-24 18:37 +0100, Stefano Lattarini wrote:
> [...]
>> On 02/24/2012 08:09 AM, Nick Bowler wrote:
>>> Automake should at least add user write permissions to all files in
>>> distdir prior to running dist-hook (and hence prior to generating the
>>> distribution tarball).
>> I disagree; in case the user wants to change the permission of the 
>> distributed
>> files from the ones that they have in the builddir/srcdir, he can do so in 
>> the
>> dist-hook already, with full control (I've just added a tiny test to verify
>> this behaviour, see attached patch).  So we don't need to change the automake
>> behaviour in this respect (but a documentation improvement might be nice, in
>> case someone feels like writing it).
> In that case, the manual should include a note that you should not
> expect "make dist" to work properly with a read-only source tree.
But it's the package that expects its distributed files to be writable
that is assuming too much; if such package wants its expectation to
safely hold, it should add something like this in its 'dist-hook':

    find $(distdir) -exec chmod u+w '{}' ';'

> Distcheck should also refrain from testing this.
Nope; distcheck testing that the distributed package builds correctly with
a read-only source tree is a feature, not a bug, since the GCS require this.
If you don't care about this requirment, than you need to provide a
'distcheck-hook' that renders your source directory writable before it
gets used by "distcheck" (I'll update my patch to have it test also such

> As I mentioned in my original mail, "make distcheck" currently attempts
> to run "make dist" with a read-only source tree,
As it should do.

> and it is causing failures in my package because of the broken
> permissions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]