On Fri, 19 May 2023 at 12:42, Steve McIntyre <st...@einval.com> wrote: > > Guillem Jover wrote: > >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > > ... > > >> > > * … but NOT on i386. Because i386 as an architecture is primarily of > >> > > interest for running legacy binaries which cannot be rebuilt against > >> > > a new > >> > > ABI, changing the ABI on i386 would be counterproductive, as > >> > > mentioned in > >> > > https://wiki.debian.org/ReleaseGoals/64bit-time. > >> > >> > Like Russ, I'm also dubious about this, and introduces a special case > >> > and complexity that does not seem warranted TBH. If this was the case it > >> > would seem to me it would disallow SOVERSION bumps for example, which we > >> > have never been concerned with. > >> > >> I didn't see anything in Russ's email in this thread that implied he was > >> dubious of this approach? He simply has a library he maintains for which > >> he > >> believes binary compatibility is uninteresting. > > > >Ah, indeed, just reread the specific paragraph now, sorry Russ! :) > > > >> FWIW in Ubuntu where we maintain i386 strictly as an architecture for > >> compatibility with third-party binaries, we have 1034 source packages that > >> build Arch: i386 debs. Not all of those source packages are shared > >> libraries, but enough of them are that manually updating them to maintain > >> ABI compatibility on i386 would be a substantial amount of work. In terms > >> of overall complexity, I think the scales tip in favor of the toolchain not > >> defaulting to _TIME_BITS=64 on i386. > > > >The problem with obsolete packages is also shared by all other arches, > >and for those and for local packages the dependency system works for > >the user and should let them know whether they can upgrade or they > >would need to remove such packages. For other local FOSS packages > >they might just be able to rebuild them. > > > >Excluding i386 from this transition seems to me will pretty much > >sentence it, and would also make it rather hard to perform that > >transition cleanly going forward if people want to keep it alive. And > >while Debian might eventually remove it from its official ports, we > >have multiple old ports that are still maintained and used. > > > >If the main reason is to support non-free binaries, at least to me > >that does not seem like a very compelling reason. And people can > >always use old chroots or similar I guess? > > i386 is in a really awkward situation here, I think. Nobody is working > on it explicitly any more (AFAICS?), but its history as by far the > most common architecture means that: > > * we still have a (very!) long tail of installations using it > * there are *massively* more old binaries available for it, free, > proprietary *and* locally-built > > Moving forwards, we need to make a call on what we want i386 for. I > was hoping to wait until after bookworm is released to have the meat > of that discussion, but... > > I'm planning on stopping publishing installer images for i386 > soon. Why? We should be strongly encouraging users to move away from > it as a main architecture. If they're still installing i386 on 64-bit > hardware, then that's a horrible mistake. If they're still running > i386 *hardware*, then they should be replacing that hardware with more > modern, more capable, more *efficient* stuff. > > As and when we switch i386 to a secondary status like this (however we > label it!), then I think we should *only* consider it as a > compatibility layer for older software. People *could* just use old > chroots or similar, but the need is likely to be around for a > while.
+1 for stopping publishing installers for i386, it has been mentioned many times but it's always worth repeating: electricity costs to keep running i386 hardware are already way higher than what it costs to buy a cheap, low-power replacement like a raspberry pi, that also provides better performance. Just to clarify, by 'soon' here, do you mean for Bookworm too, or post-Bookworm? Kind regards, Luca Boccassi
