Re: question about hardcoded binary paths (swapon / mkswap)

[Karel Zak <kzak@redhat.com>]

On Thu, Apr 02, 2015 at 09:15:22PM -0400, Mike Frysinger wrote:
> On 02 Apr 2015 21:15, Karel Zak wrote:
> > On Thu, Apr 02, 2015 at 12:19:52PM -0400, Mike Frysinger wrote:
> > > On 02 Apr 2015 10:20, Karel Zak wrote:
> > > > If I good remember then the reason is that the helpers does not have
> > > > to be installed in standard PATH. Well, you're author of this thing
> > > > :-)
> > > 
> > > i wrote the code to make it a configure option, but the actual behavior predates 
> > > me.  i'm interested more in the behavior, not the exact configure option.
> > 
> >  So, the basis question is if we really need to support non-standard
> >  paths for the helpers. IMHO it's unnecessary legacy and I don't see a
> >  problem to drop this feature and require $PATH, and for critical
> >  things like fsck fallback to /sbin if $PATH is undefined.
> 
> the reason for adding that configure option was to support packages that install 
> both into /bin and /usr/bin.  i understand some distros will override those 

I have talked about crazy things like /sbin/fs.d or /sbin/fs. The standard
paths like [/usr]/bin, [/usr]/sbin are not problem.

> settings of upstream packages, but Gentoo has opted not to since there's no 
> reason at all to force them all into /sbin (and even existing tools in /sbin are 
> pretty pointless).  although it mattered more when the code was only searching 
> that list and not $PATH at all.
> 
> my preference would be just to do execvp() and be done so we can stop these 
> distro bikesheddings (/bin & /usr-merge and such).

Yes, I thought about it too... just move the problem with PATH to libc ;-)

For example mkfs already uses execvp(), I guess we can do the same in
fsck. For mount(8) it would be better to follow the current behaviour, 
but remove nonsenses from FS_SEARCH_PATH (and rename to LIBMOUNT_HELPERS_PATH).

Volunteers? ;-)

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com