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@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
