Bruno Haible <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] $@ 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 "[EMAIL PROTECTED]" >> 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 [EMAIL PROTECTED] FWIW, my motivation for preferring [EMAIL PROTECTED] 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.
