Efraim Flashner writes:
Hello,
Toggle quote (48 lines)
> On Mon, Jul 29, 2024 at 09:21:57PM -0400, Richard Sent wrote:
>> 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.
Also, I have been "using" Guix i686-linux to for my work on bringing
i586-gnu Guix/Hurd to real 32bit hardware, by installing and
re-installing Guix/hurd from Guix/linux and dual booting. i586-gnu does
not boot on any of my older 64bit machines. A draft blog post is in the
works about this.
While this could technically also be done by installing debian-i386 and
do foreign-distro guix development, that would be far from ideal.
Toggle quote (21 lines)
> 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.
Indeed, it would be nice to at least have a basic exwm system available.
Greeings,
Janneke
--
