[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: Eric Blake
Subject: Re: bug#10878: "make dist" with read-only srcdir generates read-only tarball
Date: Fri, 24 Feb 2012 12:10:07 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1

On 02/24/2012 11:34 AM, Nick Bowler wrote:
>> 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 '{}' ';'

I agree.

> I'm not talking about building the package, which absolutely should work
> from a read-only source tree.  I'm talking about creating a distribution
> tarball, with "make dist": something only package maintainers (that's
> me!) will generally do.

That's where we are arguing that you are wrong.  The GNU Coding
Standards requires that _anyone_ can run 'make dist', and not just
'package maintainers'.  That's the whole point of software freedom:
You, as a recipient of the tarball, should be just as free to
redistribute your modifications (including rebuilding a tarball) as the
upstream maintainer you got the package from, even if you are starting
from your (possibly read-only) copy of the expanded tarball.

Which is _why_ 'make distcheck' intentionally checks that 'make dist'
from a read-only source tarball will accurately create a tarball.  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.

Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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