From: Richard Sent <richard@freakingpenguin.com>
To: Leo Famulari <leo@famulari.name>
Cc: guix-devel@gnu.org, Ricardo Wurmus <rekado@elephly.net>,
67535@debbugs.gnu.org, Efraim Flashner <efraim@flashner.co.il>
Subject: Re: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]
Date: Mon, 29 Jul 2024 21:21:57 -0400 [thread overview]
Message-ID: <87v80n8yiy.fsf@freakingpenguin.com> (raw)
In-Reply-To: <ZqgtSPDRFmqEaptq@jasmine.lan> (Leo Famulari's message of "Mon, 29 Jul 2024 20:01:12 -0400")
Leo Famulari <leo@famulari.name> writes:
> People have presented some good reasons for keeping at least some level
> of i686 support.
>
> But unfortunately, 3rd party channels cannot be one of them, whether or
> not they follow the FSDG.
>
> Of course, we won't deliberately make their work more difficult, and
> maybe we consider their needs if it's easy, but I think they shouldn't
> be considered to present compelling arguments for us to make decisions
> within GNU Guix, especially if it involves us doing extra work.
That's true enough! I don't mean to say that 3rd party channels using
i686 is sufficient reason alone to support it. I just consider it worth
keeping in mind.
In my opinion, when we ask questions like "Does anyone use X", it
doesn't really matter if that answer is "Yes, in my custom config" vs.
"Yes, in this 3rd party channel my custom config uses". The primary
distinction between the two is if the code is shared publicly. I don't
see that line in the sand being helpful when asking about usage.
To phrase this another way, if I instead said "I use multiarch
environments containing i686-linux Guix packages to run software that
can't be ported to x64" without mentioning 3rd-party channels at all,
would that suddenly become valid usage? Why?
i686 multiarch environments are useful in certain cases. Regardless of
whether those environments are provided in Guix proper, in a custom
config, or a 3rd party channel, user-facing functionality will be lost
if we remove them.
Breaking changes are okay, and if we consider this too niche of a use
case or too high of a maintenance burden it should be dropped. I do
believe it should progress into the consideration stage instead of being
discarded outright.
Thanks! :)
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
next prev parent reply other threads:[~2024-07-30 2:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ZWelMw84qtyRxxS6@jasmine.lan>
[not found] ` <ZXBoKfOxrITAuOoF@3900XT>
2024-07-26 18:51 ` Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux] Leo Famulari
2024-07-26 20:17 ` Kaelyn
2024-07-28 21:49 ` Efraim Flashner
2024-07-29 12:33 ` Ricardo Wurmus
2024-07-29 15:00 ` Richard Sent
2024-07-30 0:01 ` Leo Famulari
2024-07-30 1:21 ` Richard Sent [this message]
2024-07-30 14:39 ` Leo Famulari
2024-08-01 23:51 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-07-30 15:18 ` Efraim Flashner
2024-07-30 21:02 ` bug#67535: " André Batista
2024-08-01 20:12 ` Leo Famulari
2024-08-02 8:36 ` Ricardo Wurmus
2024-08-02 19:34 ` bug#67535: " André Batista
2024-09-05 9:42 ` Ricardo Wurmus
2024-09-05 23:52 ` André Batista
2024-08-12 14:03 ` 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=87v80n8yiy.fsf@freakingpenguin.com \
--to=richard@freakingpenguin.com \
--cc=67535@debbugs.gnu.org \
--cc=efraim@flashner.co.il \
--cc=guix-devel@gnu.org \
--cc=leo@famulari.name \
--cc=rekado@elephly.net \
/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).