Date: Tue, 4 Apr 95 19:43:54 MDT From: terry@cs.weber.edu (Terry Lambert) To: nate@sneezy.sri.com Cc: nate@trout.sri.MT.net, kargl@troutmask.apl.washington.edu, freebsd-hackers@freefall.cdrom.com Subject: Re: new install(1) utility Message-ID: <9504050143.AA25302@cs.weber.edu> In-Reply-To: <199504050103.TAA08504@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 07:03:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > Serves you right for using the install utility to do the install > > > > instead of using "cp -p". > > > > > > Ahh, and the overhead of calling chown, chgrp, and chmod is much better? > > > 'I don't think so'. > > > > Since "cp -p" preserves this information, you are saying that the > > copy in the source tree has the incorrect owner, group, and permissions. > > This is something which should be corrected in the source tree. Doing > > the correction post-facto elsewhere is bogus. > > Uhh, the permissions of the file *need* to be different in many cases > since it's awful hard to get ld to make setuid files. For include files > you want them to be writable in the src tree, but not in the > /usr/include tree, and permissions for the installations *should* NEVER, > NOT, EVER, be dependant on the permissions in the src tree. Now you are > going to make us go hack all of our source code control tools so that > they always restore the correct permissions and ownerships. > > 'cp -p' is NOT a solution. Not even close. OK, I buy the setuid output from ld; my main concern was the header files, then later the man pages; Julian correctly pointed out that this was a case of X/a -> B/a, where the target equals the source, just at a different location. I think the chmod on the target is fairly thin justification, since a chmod will only update the ctime, not the mtime, and it's the mtime that make compares. We are talking a single additional call for the chmod, and that on the "built but not installed" include directory only in case of a change in the sources, with the whole point of the exercise being to avoid unnecessary installs. I don't think you can successfully argue for a different group/owner on installed and source include files, but with permissions you've made your case. I think the subsequent include install could use cp -p without any changes to the install binary. With that in mind, you will save a subshell per actually modified include file during 50% of the installs required by the change. I still think this is pretty thin, since the whole design is trying to assume that the header files have not in fact changed. But it is arguable that instead of :w! you'd want to be non-root and use :w to save your modified include file. This thin justification is probably enough to modify the install behaviour, at least to add the "-p" option, with the ongoing maintenance that entails if the changes aren't rolled in by the original author (assuming FreeBSD does not now "own" the code). It still makes my teeth itch, but I can't suggest an alternative that makes my teeth feel any better, so I'll get out of the way. I think the dependencies that Rod, Julian, and I were talking about to prevent the calling of an "install -p" or "cp -p" in the first place need to go in. It is much less burdensome to call stat twice in a program that is already running than to fork and exec another program that then calls stat twice anyway. I would say the "install but don't really do it if they are the same" options are still not useful; the problem should be solved by correcting the Makefile dependencies instead of appologizing for them being missing with a hacked install that gets all worked up then does nothing. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504050143.AA25302>