[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.
- Re: [bug-gnulib] ensure that generated files are read-only, (continued)
- Re: [bug-gnulib] ensure that generated files are read-only, Bruno Haible, 2006/09/07
- Re: ensure that generated files are read-only, Simon Josefsson, 2006/09/07
- Re: ensure that generated files are read-only, Simon Josefsson, 2006/09/07
- Re: ensure that generated files are read-only, Ralf Wildenhues, 2006/09/07
- Re: ensure that generated files are read-only, Bruce Korb, 2006/09/07
- Re: ensure that generated files are read-only, Simon Josefsson, 2006/09/07
- Re: ensure that generated files are read-only, Ralf Wildenhues, 2006/09/07
- Re: ensure that generated files are read-only, Simon Josefsson, 2006/09/07
- Re: ensure that generated files are read-only, Bruce Korb, 2006/09/07
- Re: ensure that generated files are read-only, Simon Josefsson, 2006/09/08
Re: ensure that generated files are read-only,
Jim Meyering <=
Re: ensure that generated files are read-only, Bruno Haible, 2006/09/09
Re: ensure that generated files are read-only, Bruno Haible, 2006/09/09
Re: ensure that generated files are read-only, Jim Meyering, 2006/09/14
Re: ensure that generated files are read-only, Paul Eggert, 2006/09/14
Re: ensure that generated files are read-only, Jim Meyering, 2006/09/14
Re: ensure that generated files are read-only, Paul Eggert, 2006/09/14
Re: ensure that generated files are read-only, Jim Meyering, 2006/09/15