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

[Karel Zak <kzak@redhat.com>]

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@redhat.com>
 http://karelzak.blogspot.com