Does git belong in root's $PATH?

Does git belong in root's $PATH?

[walt]

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!

Re: Does git belong in root's $PATH?

[Andreas Ericsson]

walt wrote:
> 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)?


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).


> Does it really matter?


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.


>  (The linux distribution I use is very
> picky about what it includes in root's path...)
> 

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Does git belong in root's $PATH?

[Linus Torvalds]

On Sat, 7 Jan 2006, walt wrote:
>
> 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').

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 suppose I'm asking a philosophical question here:  do you
> guys install git where root can find it (as a system tool)?

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

Re: Does git belong in root's $PATH?

[H. Peter Anvin]

Andreas Ericsson wrote:
> 
> 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.
> 

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

Re: Does git belong in root's $PATH?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> 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".
> 

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

Re: Does git belong in root's $PATH?

[Sam Ravnborg]

On Sat, Jan 07, 2006 at 10:31:52AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 7 Jan 2006, walt wrote:
> >
> > 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').
> 
> 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?
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.

> 
> That said:
> 
> > I suppose I'm asking a philosophical question here:  do you
> > guys install git where root can find it (as a system tool)?
> 
> 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).
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 :-(

> 
> 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".

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.

> 
> 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..

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

Re: Does git belong in root's $PATH?

[Andreas Ericsson]

H. Peter Anvin wrote:
> Andreas Ericsson wrote:
> 
>>
>> 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.
>>
> 
> Hmmm... I think that was /usr/bin (hence the eventual migration of the 
> meaning of /usr from what was originally the equivalent of /home.)
> 


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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Does git belong in root's $PATH?

[H. Peter Anvin]

Andreas Ericsson 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. ;)
> 

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

	-hpa

Re: Does git belong in root's $PATH?

[walt]

H. Peter Anvin wrote:

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

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!

Re: Does git belong in root's $PATH?

[H. Peter Anvin]

walt wrote:
> H. Peter Anvin wrote:
> 
>>/usr used to be what is now called /home.  What you're describing above
>>is the current usage.
> 
> 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.)
> 

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