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

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On 03 Apr 2015 10:52, Karel Zak wrote:
> 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.

i have no problem with punting fd.d & fs subdirs.  i don't recall ever seeing a 
Linux system use them, although i've only been running things since the 2.4 
days, so maybe i'm not old enough.

> > 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? ;-)

i'll take a stab at mkfs first
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]