Re: [PATCH 1/2] Avoid another use of `chmod -R'.

[Stefano Lattarini]

At Wednesday 31 March 2010, Ralf Wildenhues <address@hidden> 
wrote:
> Stefano Lattarini wrote
> > Ralf Wildenhues wrote:
> > > I'm not sure I understand.  We are not putting any symlinks
> > > into $(distdir), why would this be needed?
> [CUT]
> > to cater for the (admittedly very unlikely) case that a
> > dist-hook will be added that puts a symlink in $(distdir), or
> > that a bug will be introduced that ends up putting a symlink in
> > $(distdir) somehow.
> 
> I wouldn't want to hide a bug preemptively, if that means it won't
>  show up here but only with user packages.
That's a good objection, but the problem with this "theoretical" bug 
is that it could manifest *silently*, and go unnoticed for a long 
time.  The better option is to extend the testsuite to preemptively 
look for the possible bug.  Once that's done, we can leave alone the 
"chmod -R" (even If I'd like a comment saying "chmod -R is safe here 
because $(distdir) doesn't contain symlinks", but that's just 
nitpicking).

> A testsuite addition that covers this would be welcome.  Be sure to
> not fail if the system doesn't support symlinks (MinGW will
> emulate ln -s with cp -p).
I'll write a couple of tests soonish, making them SKIP'd if `ln -s' 
fails, or if `test -h' fails when applied to the resulting "symlink".

By the way, how is the Automake-generated Makefile expected to behave 
if a file in e.g. EXTRA_DIST is a broken symlink, or a symlink pointing 
to a directory?  I think these corner cases should be addressed in 
some way.

Regards,
    Stefano