Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Mark H Weaver]

Hi Marius,

Marius Bakke <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>
>> address@hidden (Marius Bakke) writes:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
>>> Author: Marius Bakke <address@hidden>
>>> Date:   Mon Jul 2 12:07:58 2018 +0200
>>>
>>>     build-system/meson: Really skip the 'fix-runpath' phase on armhf.
>>>     
>>>     This follows up commit d5b5a15a4046362377f1a45d466b43bb6e93d4f which 
>>> doesn't
>>>     work because %current-system etc expands before the actual build.
>>
>> I'm disappointed by this workaround that simply removes the
>> 'fix-runpath' phase on armhf.  Is that phase needed, or is it truly
>> optional?  What does the phase accomplish, and how will armhf users be
>> disadvantaged by the removal of that phase?
>>
>> This feels like "sweeping the problem under the rug" to me.
>
> It *is* sweeping the problem under the rug, no doubt.  The only
> alternatives I can see is fixing patchelf on armhf, which is difficult
> for me without access to hardware; fixing Meson itself, which may be
> easier, but then we may not be able to merge staging in a long time; or
> implement patchelf functionality in Guix as Ludovic started with
> <https://bugs.gnu.org/31028> and is currently in 'core-updates'.
>
> Do you have other suggestions?

None that I expect to be taken seriously by this community.  I'd just
like to point out that given the way things are going, I could only
recommend Guix to x86_64 users.  Almost all of our users are on x86_64,
and they are impatient to always have the latest software.  In practice,
when upgrades would break *any* other system, we move ahead anyway, just
like we did with the last 'core-updates' merge, and just like you wish
to do now with the 'staging' branch.

The end result is that the wishes of the x86_64-using majority are the
only ones that seem to matter in this community, and other users are
frequently left in a bad spot.  This makes it increasingly unlikely that
we'll ever gain a significant number of non-x86_64 users.

I'm very troubled by this, because I intend to move away from x86_64.
Unless there is a significant change in the priorities of the Guix
project, I don't think I will be able to continue using Guix.

>>>     Fixes <https://bugs.gnu.org/31719>.
>>
>> I don't see the connection between that bug and this commit.
>> How does this commit fix that bug?
>
> Whoops, typo.  It should be <https://bugs.gnu.org/31971>.

In my view, this commit does not fix that bug.

       Mark