On Wed, Apr 01, 2015 at 10:06:52PM +0100, Ruediger Meier wrote:
> > > If "swapon" was called from PATH then just take mkswap from PATH
> > > too. If "/whatever/path/swapon" was called then look for mkswap in
> > > the same path.
It seems like over-engineering. The primary goal are regular
installations, the stuff in the test/ should not be a reason to change
important things in the utils.
> > > Maybe both cases also with or without fallback $sbindir, /sbin or
> > > $PATH.
> > >
> > > I guess we should agree how somthing like this should be handeled
> > > in general. "eject" is also using hardcoded "/bin/umount".
> >
> > seems like $PATH should always be used. if you broke $PATH, well
Yes, agree.
Note that we already have and use FS_SEARCH_PATH in mkfs, fsck and
mount (libmount), see --enable-fs-paths-default and --enable-fs-paths-extra.
Maybe we can use it use FS_SEARCH_PATH also for mkswap in swapon, or use it
as fallback.
> The only special thing here is IMO that mkswap and swapon belong to the
> same project. Should we try to use the right one per default?
>
> Example:
> UL is installed below /usr/local
> PATH="/usr/local/sbin:/sbin"
>
> Explicitly invoking the (old) globally installed /sbin/swapon should use
> the old /sbin/mkswap too or the new /usr/local/sbin/mkswap from PATH?
I'd like to avoid complex and not obvious semantic. It's fine to
follow PATH or harcoded FS_SEARCH_PATH.
> Another point:
> If "/sbin" is not in PATH should "sudo /sbin/swapon" find /sbin/mkswap
> or not?
Is it really our problem? I don't think we have to provide solutions
for all crazy scenarios...
Note that for critical things (for example things important for system
boot, etc.) there should be always hardcoded fallback.
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
