Hi!

On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote:
> Guillem Jover wrote:
> >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:
> >> > […], 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.

Err, sorry the SOVERSION example does not make sense here, precisely
because in those cases the dependency system works for the user and
(in general) should let the old versions of those shared libraries
even if now obsolete packages be co-installed along the new versions.

> >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?),

I assume because it seems to "work" and people might have not seen the
need to jump in, compared to say if it was in ports.d.o, but I might be
wrong.

> 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...

> […]

> 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.

> There's a tension here: I think it's important to keep the old ABI
> around for those old binaries, and I genuinely don't see a use case
> for a new incompatible ABI on a mostly-dead architecture that won't
> support those binaries. *But* I think we'll also need to keep the port
> going with security fixes - it's still likely to be quite common and
> we need to keep users safe.

> People are even likely to want to keep old software running beyond
> 2038, in which case I envisage clock hacks coming to keep things
> limping on. :-/

So I guess my concern is three fold:

  a) There's the part that I mentioned where excluding it means it is
     destined to die in exchange for that backwards binary compat,
     although it's not clear for how long this all will be supported
     by Debian (and where I consider I've registered my concern here,
     but if people in general think the backwards compat trumps other
     stuff I'm fine with that).
  b) I still keep at least one 32-bit Athlon system around mostly to
     be able to support 3Dfx hardware, which I'll have to stop
     supporting either when the machine, the port or time dies. OTOH
     I've been pondering stopping the support in the future anyway so
     it's not such a great concern for me.
  c) And then there's the port support long term in dpkg, where my
     expectation is that when and if Debian does not officially support
     it, people that might still want to use that port on vintage
     hardware will most probably request to flip the switch, and then
     me and/or the ports.d.o maintainers might need to decide between
     users that have expected such backwards compat and porters that
     might want to be able to continue using the port. :/

(I also keep that Athlon around as I need to recover data from a bunch
of 3.5" floppy disks! But that should stop being relevant once I sit down
through the drudge of changing the piles of disks every few minutes. :)

Thanks,
Guillem

Reply via email to