Efraim Flashner writes: Hello,
> On Mon, Jul 29, 2024 at 09:21:57PM -0400, Richard Sent wrote: >> Leo Famulari <l...@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. > 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 -- Janneke Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
