[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Architecture baseline for Forky



On Thu, Oct 30, 2025, at 15:07, Adrian Bunk wrote:
> On Wed, Oct 29, 2025 at 02:47:13PM +0100, Arnd Bergmann wrote:
>> On Wed, Oct 29, 2025, at 08:39, Adrian Bunk wrote:
> Regarding option 5:
>
> The baseline is encoded in a gazillion places, these need fixes
> (though raspbian already has fixes for most).
>
> And then you need a rebuild of the full archive.
>
> It might be doable to basically merge raspbian into Debian
> (but it would be weird to do that now and not a decade ago).
>
> A relevant question would be how many and which packages are not 
> buildable on raspbian due to the lower baseline.
>
> In any case this option would be a lot of work.

Right

> Regarding option 3:
>
> The amount of work would be trivial, since asking the GCC maintainer
> to change the baseline would be the only mandatory part of the change
> (we did this on armel when raising the baseline from armv4te to armv5te
> in buster).
>
> Due to the common baseline without NEON most relevant software that 
> benefits from NEON got runtime detection 1-2 decades ago.
>
> Due to armhf being a legacy platform today, it is unlikely that 
> important software will suddenly make NEON a hard requirement
> now - it is more common that a package drops  armhf support,
> or more commonly support for 32-bit.
>
> If the only tradeoff is between hardware support and marginal 
> performance improvements, that's not a good case for dropping
> hardware support - and anyone who cares about performance
> should anyway not be using armhf in 2027.

I see two scenarios where moving to a NEON makes sense beyond
the performance difference:

- packages that have already introduced a NEON dependency, either
  intentionally from upstream, or by accidentally using the
  wrong compiler flags in some place. Right now, these
  would be considered a bug that requires someone to fix it
  (or to drop the package from armhf).

- packages that are currently patched in Debian to avoid a
  NEON dependency in the upstream code. Those patches could be
  dropped as a simplification.

I think I have seen both in the past, but don't know how
common they are across the entire archive.

     Arnd


Reply to: