On Mon, Jul 29, 2024 at 09:21:57PM -0400, Richard Sent wrote:
Toggle quote (40 lines)
> 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! :)
I would argue that some of the bootstrapping effort which is i686
specifically and can't be easily ported to x86_64 (such as compilers)
are a perfectly fine reason to need something to be built natively vs
cross-compiled. Another email mentioned wine, which, while I don't
believe it is currently possible to cross-compile in guix, may or may
not work correctly when used cross-compiled as an input for wine64.
Without directly answering the question of "is the phrasing wrong" vs
"is the burden too high", IMO there's not really a difference between a
package in a separate channel vs a custom package in someone's config,
other than how easy it is to share. If we said, despite the move to Qt6
and upstream chromium dropping support for 32-bit architectures and thus
affecting i686 support in qtwebengine, that it was imperative that i686
keep a working qtwebengine and that we couldn't upgrade it unless we
knew it worked on i686 that might be a problem due to "The Dangers of
the Internets", but ongoing work to update patches to keep it working
would be good. Or I suppose another example is if we froze Gnome at a
version that supported the old librsvg because the new one depends on
rust, instead we've worked around it so that those that can't use the
new one use the old one, and those packages which can't use the old one
specifically use the new one, with the side effect that gnome isn't
supported on all architectures.
I would not be against selecting some scientific packages and marking
them as 64bit only with a note that although they might build on 32bit
architectures, they would never be used there and there is no reason to
try to even build them.
--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
