Re: Bug#953537: xfsdump fails to install in /usr merged system.

[Dave Chinner <david@fromorbit.com>]

On Fri, Jun 19, 2020 at 12:03:35PM -0500, Eric Sandeen wrote:
> On 6/18/20 11:47 PM, Darrick J. Wong wrote:
> > On Fri, Jun 19, 2020 at 05:05:00AM +0100, peter green wrote:
> >> (original message was sent to nathans@redhat.com
> >> 953537@bugs.debian.org and linux-xfs@vger.kernel.org re-sending as
> >> plain-text only to linux-xfs@vger.kernel.org)
> >>
> >> This bug has now caused xfsdump to be kicked out of testing which is
> >> making amanda unbuildable in testing.
> > 
> > Uhoh...
> > 
> >>
> >>
> >>> Yes, what's really needed here is for a change to be merged upstream
> >>> (as all other deb packaging artifacts are) otherwise this will keep
> >>> getting lost in time.
> >> To make it easier to upstream this I whipped up a patch that should
> >> solve the issue while only modifying the debian packaging and not
> >> touching the upstream makefiles. It is attached to this message and if
> >> I get no response I will likely do some further testing and then NMU
> >> it in Debian.
> >>
> >> One issue I noticed is it's not all all obvious who upstream is. The
> >> sgi website listed in README seems to be long dead and there are no
> >> obvious upstream results in a google search for xfsdump. Gentoos page
> >> on xfsdump links to https://xfs.wiki.kernel.org but that page makes no
> >> mention of xfsdump.
> >>
> >> I eventually poked around on git.kernel.org and my best guess is that
> >> https://git.kernel.org/pub/scm/fs/xfs/xfsdump-dev.git/ is the upstream
> >> git repository and linux-xfs@vger.kernel.org is the appropriate
> >> mailing list, I would appreciate comments on whether or not this is
> >> correct and updates to the documentation to reflect whatever the
> >> correct location is.
> > 
> > Yep, you've found us. :)
> > 
> > Uh... seeing how /sbin seems to be a symlink to /usr/sbin on more and
> > more distros now, how about we just change the upstream makefile to dump
> > them in /usr/sbin and forget all about the symlinks?
> > 
> > (He says, wondering what the actual maintainer will say...)
> 
> I wonder too :P
> 
> So, FWIW, fedora/rhel packaging also hacks this up :(

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:

.....
#
# Some important tools should be installed into the root partitions.
#
# Check whether exec_prefix=/usr: and install them to /sbin in that
# case.  If the user choses a different prefix assume he just wants
# a local install for testing and not a system install.
#
case $exec_prefix:$prefix in
NONE:NONE | NONE:/usr | /usr:*)
  root_sbindir='/sbin'
  root_libdir="/${base_libdir}"
  ;;
*)
  root_sbindir="${sbindir}"
  root_libdir="${libdir}"
  ;;
esac

AC_SUBST([root_sbindir])
AC_SUBST([root_libdir])

....

I suspect that this "system install" logic - which once made sense -
doesn't work at all with symlinked /sbin setups.

IIRC debian is in a transistion stage where it will accept either
types of package, but people trying to install a "linked /sbin only"
system will be reporting issues where pacakges do the wrong thing...

> xfsdump does:
> 
> %install
> rm -rf $RPM_BUILD_ROOT
> make DIST_ROOT=$RPM_BUILD_ROOT install
> # remove non-versioned docs location
> rm -rf $RPM_BUILD_ROOT/%{_datadir}/doc/xfsdump/
> 
> # Bit of a hack to move files from /sbin to /usr/sbin
> (cd $RPM_BUILD_ROOT/%{_sbindir}; rm xfsdump xfsrestore)
> (cd $RPM_BUILD_ROOT/%{_sbindir}; mv ../../sbin/xfsdump .)
> (cd $RPM_BUILD_ROOT/%{_sbindir}; mv ../../sbin/xfsrestore .)
> 
> xfsprogs does:
> 
> %install
> make DIST_ROOT=$RPM_BUILD_ROOT install install-dev \
>         PKG_ROOT_SBIN_DIR=%{_sbindir} PKG_ROOT_LIB_DIR=%{_libdir}

So the fedora rpm package build is overriding the locations that
autoconf set in include/builddefs for the install on the make
command line?

> Both of these work around the default location of /sbin:
> 
> # grep PKG_ROOT_SBIN_DIR xfsprogs-maint/include/builddefs xfsdump/include/builddefs
> xfsprogs-maint/include/builddefs:PKG_ROOT_SBIN_DIR = /sbin
> xfsdump/include/builddefs:PKG_ROOT_SBIN_DIR = /sbin

Ok, it is.

So my question is this: what magic should we be putting in autoconf
to have it automatically detect that the package should build for a
linked /sbin and have the build always do the right thing via "make
install"?

> On one hand, it'd be easy enough to change the upstream defaults I guess.
> On the other hand, I think the PKG_ROOT_SBIN_DIR method is easy too.
> 
> How does debian fix this for xfsprogs?  Doesn't the same issue exist?

AFAICT, yes, it does exist. The buildroot from a recent package
build:

$ ls -l xfsprogs-5.7.0-rc0/debian/xfsprogs/sbin
total 928
-rwxr-xr-x 1 dave dave   1968 May 21 15:41 fsck.xfs
-rwxr-xr-x 1 dave dave 367584 May 21 15:42 mkfs.xfs
-rwxr-xr-x 1 dave dave 573536 May 21 15:42 xfs_repair
$

xfsprogs also appears to be packaging binaries in /sbin, too.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com