Re: [PATCH] kconfig: dont hardcode path to lsmod
From: John Kacur
Date: Tue Jan 19 2010 - 13:12:54 EST
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).
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.