Re: [PATCH 3/4] debian: Regenerate config.guess using debhelper

From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Steve Langasek <steve.langasek@canonical.com>,
	Bastian Germann <bastiangermann@fishpost.de>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/4] debian: Regenerate config.guess using debhelper
Date: Wed, 24 Feb 2021 07:51:29 +1100	[thread overview]
Message-ID: <20210223205129.GY4662@dread.disaster.area> (raw)
In-Reply-To: <957b9913-bcdb-b64c-4c33-6493a91b3838@sandeen.net>

On Mon, Feb 22, 2021 at 01:23:12PM -0600, Eric Sandeen wrote:
> On 2/21/21 8:44 PM, Dave Chinner wrote:
> > On Sun, Feb 21, 2021 at 04:16:39PM -0800, Steve Langasek wrote:
> >> On Mon, Feb 22, 2021 at 09:04:43AM +1100, Dave Chinner wrote:
> >>
> >>>> This upstream release ended up with an older version of config.guess in
> >>>> the tarball.  Specifically, it was too old to recognize RISC-V as an
> >>>> architecture.
> >>
> >>> So was the RISC-V architecture added to the ubuntu build between the
> >>> uploads of the previous version of xfsprogs and xfsprogs-5.10.0? Or
> >>> is this an actual regression where the maintainer signed tarball had
> >>> RISC-V support in it and now it doesn't?
> >>
> >> This is a regression.  The previous tarball (5.6.0) had a newer config.guess
> >> that recognized RISC-V, the newer one (5.10.0) had an older config.guess.
> > 
> > Ok.
> > 
> > Eric, did you change the machine you did the release build from?
> 
> I don't recall doing so, but I must have. I guess I remember this coming up
> a while ago and maybe I failed to change process in a sticky way.  :/
> 
> But - if my local toolchain can cause a regression in a major distro, it seems
> like this patch to regenerate is the obvious path forward, to control
> the distro-specific build, and not be subject to my personal toolchain whims.

I think it's on the package maintainer to ensure what is uploaded as
the official distro package contains the correct tarball contents
for their distro. If the distro build overrides shipped config
files, then there shouldn't be any problems at all with just using
the upstream tarball.

> Is that not best practice? (I honestly don't know.)

Honestly, I think building packages from tarballs is an anachronism
of a time gone by. Debian xfsprogs packages can be build directly
from a clean git tree and none of these problems exist in that case.
i.e. a clean git tree requires the build to libtoolize/autoconf and
set up the source tree from it's environment before anything else,
hence there's nothing that needs to be overridden...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com