Re: [PATCH] kconfig: dont hardcode path to lsmod

[John Kacur <jkacur@redhat.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1788 bytes --]



On Tue, 19 Jan 2010, Mike Frysinger wrote:

> On Tue, Jan 19, 2010 at 12:42, John Kacur wrote:
> > On Tue, Jan 19, 2010 at 6:23 PM, Mike Frysinger wrote:
> >> On Tue, Jan 19, 2010 at 09:25, Américo Wang wrote:
> >>> On Tue, Jan 19, 2010 at 01:52:00AM -0500, Mike Frysinger wrote:
> >>>>The lsmod utility has always been installed into /bin with the newer
> >>>>module-init-tools package, so let lsmod be found via PATH instead of
> >>>>hardcoding the old modutils /sbin path.
> >>>>
> >>>
> >>> Some distro doesn't set /sbin to PATH, so for me a better solution
> >>> would be making PATH contain /sbin, and then use "lsmod".
> >>
> >> read my changelog -- module-init-tools has always installed into /bin.
> >>  so what your distro does with /sbin doesnt matter.
> >
> > I prefer my patches work for the real-world instead of the "so what
> > your distro does doesn't matter" world.
> 
> try reading my comment instead of getting huffy.  if you have a distro
> that does something stupid like break the correct default m-i-t
> install setup, you should actually point it out.  the ones i checked
> were sane and installed lsmod into /bin (and some symlinked lsmod for
> backwards compat with modutils into /sbin).
> -mike

Well, I'm currently running Fedora (10 thru 12), and lsmod is in /sbin
Your patch would still not break for me because /sbin is in the PATH.

However if Américo is correct that there are distros that have lsmod in
/sbin and don't have /sbin in the PATH, then your patch would break them.
You can argue that the distro is doing something stupid, but I'll bet you
they will blame your patch for breaking them. It seems reasonable to 
me that a distro might only put /sbin in the superuser path, so I can 
imagine there are cases like Américo suggests.

Thanks.