On Fri, Jun 19, 2020, at 19:10, peter green wrote: > Putting the debian bug back in cc, previous mails are visible at > https://marc.info/?l=linux-xfs&m=159253950420613&w=2 > > On 19/06/2020 23:43, Dave Chinner wrote: > > > Isn't the configure script supposed to handle install locations? > > Both xfsprogs and xfsdump have this in their include/builddefs.in: > > > > PKG_ROOT_SBIN_DIR = @root_sbindir@ > > PKG_ROOT_LIB_DIR= @root_libdir@@libdirsuffix@ > > > > So the actual install locations are coming from the autoconf setup > > the build runs under. Looking in configure.ac in xfsprogs and > > xfsdump, they both do the same thing: > > > The issue is that xfsdump installs the programs in /sbin but it *also* > creates symlinks in /usr/sbin, > presumablly at some point the binaries were moved to /sbin but the > developers wanted to keep > packages that hardcoded the paths working. > > Those symlinks are suppressed if installing directly to a merged-usr > system, which is fine for > end-users installing the program directly but isn't useful if > installing to a destination dir for > packaing purposed.
Seems proper thing to do is install xfsdump/xfsrestore where the files are supposed to live and allow a packaged version to forego installing the symlinks by configuring with an appropriate --without option. Even if installing a symlink is expected (the --without option is not supplied), a test should be performed after installing the real binaries to determine if the symlinks are unnecessary (path already exists and either contains the requisite symlink or contains the just installed binary via symlink, bind mount, or whatever.) Joseph
