Re: isa-support -- exit strategy?
Hi Adam,
I think the problems that apt/dpkg
are trying to deal with is already complicated enough, and
the architecture specific code are still not significant
enough to introduce change there.
Indeed supporting number crunching programs on ancient
hardware is not meaningful, but the demand on Debian's
support for number crunching is not that strong according
to my years of observation.
For popular applications that can take advantage of above-baseline
instruction sets, they will eventually write the dynamic code
dispatcher and add the fallback.
For applications seriously need performance, they will
leave CPU and go to GPU or other hardware. If the user correctly
write the code and fully leverage GPU, the non-optimal CPU
code won't necessarily be a bottleneck.
For applications seriously need CPU performance, they are
possibly going to tell the users how to tweak compiling
parameters and how to compile locally.
Eventually, my thoughts about above-baseline support are
still either source-based package distribution like portage, or
small deb repository built with a customized dpkg-dev, like
I mentioned in the past.
On Fri, 2022-03-25 at 23:34 +0100, Adam Borowski wrote:
> Hi!
> While packages are allowed to not support entire architectures
> outright, there's a problem when some code requires a feature that is
> not present in the arch's baseline. Effectively, this punishes an
> arch
> for keeping compatibility. The package's maintainers are then
> required
> to conform to the baseline even when this requires a significant work
> and/or is a pointless exercise (eg. scientific number-crunching code
> makes no sense to run on a 2002 box).
>
> With that in mind, in 2017 I added "isa-support" which implements
> install-time checks via a dependency. Alas, this doesn't work as
> well
> as it should:
>
> * new installs fail quite late into installation process, leaving you
> with a bunch of packages unpacked but unconfigured; some apt
> frontends don't take this situation gracefully.
>
> * upgrades when an existing package drops support for old hardware
> are
> even worse.
>
> * while a hard Depends: works for leafy packages, on a library it
> disallows having alternate implementations that don't need the
> library in question. Eg, libvectorscan5 blocks a program that
> uses it from just checking the regexes one by one.
>
> Suggestions?
>
>
> Meow!
Reply to: