Does git belong in root's $PATH?

When updated my kernel this morning, the same way I've been doing it for many months, I noticed that the -gxxxxxxx localversion string was missing from the new kernel's name.

I finally figured out that this happened because /usr/local/bin is not in my root's $PATH, and the setlocalversion script depends on git. (The only thing I do as root is 'make install').

I suppose I'm asking a philosophical question here: do you guys install git where root can find it (as a system tool)? Does it really matter? (The linux distribution I use is very picky about what it includes in root's path...)

Thanks!

walt wrote:

I install it in /usr/bin. I don't *use* the git-tools as root though, so I don't feel there's anything to worry about (well, at least no more than for the other 2847 programs living in my $PATH).

Theoretically, yes, but only if someone can trick you to, as root, doing something with git which triggers some yet undiscovered bug and makes it run code it was never meant to.

Not including /usr/local/{bin,sbin} in root's path is considered wise, since, historically, that's where users would install their own versions of programs that the system doesn't provide. This use has largely been obsoleted by $HOME/bin as the default for user-specific programs, mainly because of disks getting larger and cheaper.

Andreas Ericsson wrote:

Hmmm... I think that was /usr/bin (hence the eventual migration of the meaning of /usr from what was originally the equivalent of /home.)

Today /usr/local is strictly a location for site-local things; a place that won't conflict with the distribution.

	-hpa

H. Peter Anvin wrote:

I've been told that it's '/usr' simply because that's where user interface tools that have nothing to do with boot-strapping resides. A point emphasized by the fact that /bin, /sbin and /lib must not reside on network-mounted media, while /usr may.

It seems so logical I never bothered to look in to find out for myself though, so I may well be wrong, or at least younger. ;)

Andreas Ericsson wrote:

/usr used to be what is now called /home. What you're describing above is the current usage.

	-hpa

H. Peter Anvin wrote:

History lessons are valuable for us youngsters ;o) Can you give us a brief description of what motivated such a change? (Just as important, of course, is whether the original motives have changed or disappeared.)

Thanks!

walt wrote:

This is the history as far as I understand it. Keep in mind I was only 8 years old in 1980, and I think I first learned about how Unix worked in 1985 or 1986, so not all of this is first-hand.

/usr was initially used for home directories (user directories.) Both fore reasons as have been previously discussed (remember, most easy multi-user systems were a lot friendlier than one would expect today), and because the root disk often filled up, it became common for users to put binaries in /usr/bin, and often the sysadmin, too.

As the need for system security tightened, by the 80's this was a pretty unusable configuration. Since home directories were specified in /etc/passwd, those could, and often were, located elsewhere -- much easier than trying to change the now-established conventions of /usr/bin et al. A lot of systems in the 80's were massively multiuser anyway (workstations were coming in but were rare), and so you'd frequently see paths like /u2/h/hpa for example (my actual home directory location on our college server.)

The convention of using /home for home directories seems to have evolved out of necessity when networking came in use on a large scale (NFS, automounter, etc), probably in the late 80's-early 90's. By the time Linux emerged in 1991 it was pretty well-established on smaller systems; larger systems still tended to use local conventions inherited from previous generation systems.

	-hpa

On Sat, 7 Jan 2006, walt wrote:

Ok, sounds like a build buglet to me. If you've done a "make" as a regular user, and just do a "make install" as root, I'd argue that the "make install" should do as little as humanly possible, and literally just install the kernel. If it starts changing the version, that sounds a bit fishy.

Sam, anything we can do?

That said:

I don't, but I don't use "make install" anyway, I just do "make modules_install". I install the kernel by hand, I always have.

Of course, that's partly because I've always felt that "make install" does too much (I think "make modules_install" is better - it really only installs the already-built modules).

Maybe it would be best to remove the "vmlinux" dependency from "make install" (so that "make install" will do exactly that: just install). I think all the documentation already tells you to do a "make" and then a "make install".

The other make targets really _are_ different: "make fdimage" depends on vmlinux, but that's because it literally just builds the image. "make install" is special.

Sam, what say you? I forget what the kbuild mailing list is, but maybe you can forward this suggestion there..

		Linus

Linus Torvalds wrote:

I would very much agree with this change; it's a nuisance that "make install" can't be cleanly run as root without leaving root turds in the build directory.

(Speaking as the person who did the original "make install" patch about 12 years ago.)

	-hpa

On Sat, Jan 07, 2006 at 10:31:52AM -0800, Linus Torvalds wrote:

Today kbuild uses same method to build KERNELRELEASE no matter what target is used, and I recently committed a change that used git tools as replacement for direct manipulation with .git/* What I did not realise was that we now require git during make install time - which is obviously plain wrong.

I will try to look into a cleaner solution tomorrow where KERNELRELEASE is fetched somewhere else during make install time.

The big difference here is that "make modules_install" is part of kbuild, whereas "make install" almost just call installkernel which is distribution specific - and the distributions does all sort of stuff in installkernel :-(

I had a short chat with David Miller about something similar. What I really liked to do was to tell user if vmlinux needed an update. But the implmentation of kbuild does make this almost impossible - I have at least not seen how to do it.

When I during early 2.6.12 removed the dependency on vmlinux from the install target people were complaining that there scripts broke and the solution that was implmented was a new target: "make kernel_install" and "make install" got back the vmlinux dependency.

Only difference between the two are that "make kernel_install" does NOT have vmlinux as prerequisite. This was btw only done for i386 and the only other architecture that have kernel_install is parisc with a vmlinux dependency.

So no, I'm very unlikely to remove the vmlinux dependency from the "make install" target - it results in too many suprises.

These days it is named linux-kernel@vger.kernel.org ;-) kbuild-devel@lists.sourceforge.net is seldom used though I still monitor it. Talked with mec about discontinue it but he liked to keep it araound. He is btw still moderator on that list filtering away all spam.

	Sam