From: Mark H Weaver <mhw@netris.org>
To: Marius Bakke <mbakke@fastmail.com>
Cc: guix-devel@gnu.org
Subject: Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.
Date: Tue, 03 Jul 2018 15:20:08 -0400 [thread overview]
Message-ID: <87efgknn2v.fsf@netris.org> (raw)
In-Reply-To: <877emdwm0f.fsf@fastmail.com> (Marius Bakke's message of "Mon, 02 Jul 2018 20:06:08 +0200")
Hi Marius,
Marius Bakke <mbakke@fastmail.com> writes:
> Mark H Weaver <mhw@netris.org> writes:
>
>> mbakke@fastmail.com (Marius Bakke) writes:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
>>> Author: Marius Bakke <mbakke@fastmail.com>
>>> 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
next prev parent reply other threads:[~2018-07-03 19:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180702101757.22792.51026@vcs0.savannah.gnu.org>
[not found] ` <20180702101758.97A6020543@vcs0.savannah.gnu.org>
2018-07-02 17:29 ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Mark H Weaver
2018-07-02 18:06 ` Marius Bakke
2018-07-03 19:20 ` Mark H Weaver [this message]
2018-07-04 7:21 ` Ludovic Courtès
2018-07-04 19:55 ` RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.) Mark H Weaver
2018-07-04 22:32 ` Kei Kebreau
2018-07-05 8:39 ` Ludovic Courtès
2018-07-05 14:15 ` Kei Kebreau
2018-07-05 9:04 ` Jonathan Brielmaier
2018-07-05 19:40 ` Andreas Enge
2018-07-05 6:38 ` Ricardo Wurmus
2018-07-05 8:46 ` Ludovic Courtès
2018-07-05 9:52 ` Andreas Enge
2018-07-05 8:50 ` Ludovic Courtès
2018-07-05 9:01 ` Ludovic Courtès
2018-07-02 18:28 ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Marius Bakke
2018-07-03 19:24 ` Mark H Weaver
2018-07-04 7:27 ` Ludovic Courtès
2018-07-04 14:27 ` Marius Bakke
2018-07-03 21:28 ` Ludovic Courtès
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87efgknn2v.fsf@netris.org \
--to=mhw@netris.org \
--cc=guix-devel@gnu.org \
--cc=mbakke@fastmail.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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).