Adam Borowski wrote: > * 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. Maybe install isa-support by default and add an apt hook similar to the apt-listbugs one that blocks installation of unsupported packages before the installation process starts. > * upgrades when an existing package drops support for old hardware are > even worse. As above, but this approach is pretty terrible with automated upgrades, so there probably needs to be a way for hooks to communicate with automated upgrade tools that certain packages should not be upgraded. > * 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. Libraries really should do runtime CPU detection themselves and return failure when the current CPU isn't supported, then applications using them can fall back on alternative solutions. > Suggestions? Install time is a suboptimal time for deciding whether or not a certain package is supported on the CPU installed during the current boot of a system. Live images run on many different CPUs. I have run a regular Debian install from an external USB hard drive on many different computers at different internet cafes. People often move their hard drive from an old/failed computer to a new computer. A better option might be to always allow installation, but have an apt hook or feature that warns or asks for confirmation when you install packages that are not supported on your current CPU, along with an executable that can check the CPU is supported, and print an error to stderr/X11/Wayland as appropriate and execute the command otherwise. An sse4-support symlink could point to an isa-support executable, which could check $0 against the CPU and either do the warning or exec "$@", then maintainers could call sse4-support from wrapper scripts etc. The errors could be done by different executables so that the errors fit in with the desktop that is currently in use if any. It might be worth looking at how things like Steam and Flatpak/Snap solve this issue, I expect games and proprietary apps often use CPU features unsupported on old systems. I also wonder if qemu could be used to emulate newer CPU features on older systems. That would probably be unusably slow though. It is probably worth initiating a cross-distro discussion about this. The above idea could even become a cross-distro solution to this issue. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part