public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: peter green <plugwash@p10link.net>, Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Bug#953537: xfsdump fails to install in /usr merged system.
Date: Thu, 18 Jun 2020 21:47:34 -0700	[thread overview]
Message-ID: <20200619044734.GB11245@magnolia> (raw)
In-Reply-To: <998fa1cb-9e9f-93cf-15f0-e97e5ec54e9a@p10link.net>

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...)

--D

> diff -Nru xfsdump-3.1.9/debian/changelog xfsdump-3.1.9+nmu1/debian/changelog
> --- xfsdump-3.1.9/debian/changelog	2020-01-31 17:30:58.000000000 +0000
> +++ xfsdump-3.1.9+nmu1/debian/changelog	2020-06-19 01:01:18.000000000 +0000
> @@ -1,3 +1,13 @@
> +xfsdump (3.1.9+nmu1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Create and remove symlinks in postinst/preinst rather than including them
> +    in the package to support merged user systems. Based on a patch from
> +    Goffredo Baroncelli but adjusted to avoid the need for modifying upstream
> +    non-debian files. ( Closes: 953537 )
> +
> + -- Peter Michael Green <plugwash@debian.org>  Fri, 19 Jun 2020 01:01:18 +0000
> +
>  xfsdump (3.1.9) unstable; urgency=low
>  
>    * New upstream release
> diff -Nru xfsdump-3.1.9/debian/rules xfsdump-3.1.9+nmu1/debian/rules
> --- xfsdump-3.1.9/debian/rules	2020-01-31 17:30:58.000000000 +0000
> +++ xfsdump-3.1.9+nmu1/debian/rules	2020-06-19 01:01:18.000000000 +0000
> @@ -44,6 +44,9 @@
>  	-rm -rf $(dirme)
>  	$(pkgme) $(MAKE) -C . install
>  	$(pkgme) $(MAKE) dist
> +	#remove the symlinks in /usr/sbin, the postinst will create them
> +	#if appropriate for the users system 
> +	rm -f debian/xfsdump/usr/sbin/xfsdump debian/xfsdump/usr/sbin/xfsrestore
>  	dh_installdocs
>  	dh_installchangelogs
>  	dh_strip
> diff -Nru xfsdump-3.1.9/debian/xfsdump.postinst xfsdump-3.1.9+nmu1/debian/xfsdump.postinst
> --- xfsdump-3.1.9/debian/xfsdump.postinst	1970-01-01 00:00:00.000000000 +0000
> +++ xfsdump-3.1.9+nmu1/debian/xfsdump.postinst	2020-06-19 00:59:32.000000000 +0000
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +set -e
> +
> +if [ "$1" = 'configure' ]; then
> +  for file in xfsdump xfsrestore; do
> +    if [ ! -e /usr/sbin/$file ]; then
> +      ln -s /sbin/$file /usr/sbin/$file
> +    fi
> +  done
> +fi
> +
> +#DEBHELPER#
> diff -Nru xfsdump-3.1.9/debian/xfsdump.preinst xfsdump-3.1.9+nmu1/debian/xfsdump.preinst
> --- xfsdump-3.1.9/debian/xfsdump.preinst	1970-01-01 00:00:00.000000000 +0000
> +++ xfsdump-3.1.9+nmu1/debian/xfsdump.preinst	2020-06-19 01:01:18.000000000 +0000
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +set -e
> +
> +if [ "$1" = 'remove' ]; then
> +  for file in xfsdump xfsrestore; do
> +    if [ -L /usr/sbin/$file ]; then
> +      rm /usr/sbin/$file
> +    fi
> +  done
> +fi
> +
> +#DEBHELPER#


  reply	other threads:[~2020-06-19  4:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19  4:05 Bug#953537: xfsdump fails to install in /usr merged system peter green
2020-06-19  4:47 ` Darrick J. Wong [this message]
2020-06-19 17:03   ` Eric Sandeen
2020-06-19 22:43     ` Dave Chinner
2020-06-20  2:10       ` peter green
2020-06-20 23:21         ` Dave Chinner
2020-06-20  2:36     ` peter green
2020-06-20  2:38   ` peter green

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200619044734.GB11245@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=plugwash@p10link.net \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox