[Top][All Lists]

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

Re: ensure that generated files are read-only

From: Jim Meyering
Subject: Re: ensure that generated files are read-only
Date: Fri, 08 Sep 2006 00:09:11 +0200

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> I've always taken the stand that
>> generated files should be read-only, and this is just another
>> reason to follow that policy.
> I'm vehemently opposed to such a change. On the contrary, I think the
> policy should be that in a distrib tarball, _all_ files and directories
> should be writable.

Bear in mind that there is a significant gap between what happens
at bootstrap time, or build time and the creation of a distribution tarball.
I.e., there are plenty of opportunities to automate the process of
changing permissions to making all files owner-writable.

> The reasons are:
> 1) For the user who unpacks and builds a package.
>    When he wants to remove the package, he will do "rm -r coreutils-6.2".
>    This will start asking questions. So he types Ctrl-C, and does
>    "rm -rf coreutils-6.2". And next time he will possibly use "rm -rf"
>    to avoid the problem.
>    But "rm -rf" removes anything, without safety measures. If he makes
>    a typo, he is hosed!
>    So by declaring some files read-only, you are degrading the safety
>    of users because they get accustomed to "rm -rf".

Personally, I don't find rm -rf so dangerous,
but I do see how others might.  So I'll remove
the chmod commands I added.  I contend that the
rm -f address@hidden $@ commands should stay, since otherwise
the rule will fail whenever the target is read-only.

>    In other words, IMO, the read-only status should be reserved to
>    precious files.
> 2) For the user who needs to fix a compilation problem, or do minor
>    developments in a package.
>    In this case I _do_ want to change the Makefile or config.h, to see
>    the results. Because if I change Makefile.am or *.m4, I will have to
>    wait 5 minutes until aclocal, automake, autoheader, configure have
>    completed their business. Or even worse, I will get errors because
>    I don't have the "right" automake and autoconf versions installed.
>    When I modify a Makefile and, when trying to save it, am told
>    that I cannot save it, it's a major annoyance.

If it's really a major annoyance, you should switch to
an editor that lets you circumvent such things more easily.
In Emacs, C-xC-q is the typical binding to toggle read-only.
For Vi, to save a file owned by you, in spite of its read-only
setting, just use :w!

>    Furthermore, people who have not yet understood the complete machinery
>    don't know which file to modify to get a certain modification.
>    Sometimes I get fix suggestions from people who hand-modified the
>    'configure' file or so. If they are not able to do so, because
>    'configure' is read-only, they will likely not send anything useful,
>    maybe no bug report at all.
>> Note that this does affect modules/* files owned by others.
>> If anyone objects, I'll quickly revert the objectionable change.
> Please revert. It is not acceptable for me to have read-only files in a
> gettext or libiconv distribution.
>> Bruno, would you mind if I changed the uses of "t-$@" to "address@hidden"
>> in modules/localcharset?
> Yes. The rule would not work right any more on 8+3 filesystems (DJGPP,
> possibly also OS/2).

Do you know of actual users who have to _build_ GNU tools on 8+3
filesystems?  Or even any who merely want to, but with a good reason?
If so, maybe they're museum curators :) Otherwise, how do you explain
that those people don't complain about any of the 20 other modules/rules
in which it is spelled address@hidden

FWIW, my motivation for preferring address@hidden is that it works also when $@
happens to be an absolute file name.  t-$@ would fail in that case.

I was wondering about the 14-byte file name length limitation that
we've worried about over the years.  But it's been so long since anyone
has reported a problem with longer names, that I suspect they dropped
out of common usage some time ago.  If the 14-byte limitation is gone,
then certainly the 8+3 one has been gone for even longer.

reply via email to

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