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

isa-support -- exit strategy?



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!
-- 
⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
⠈⠳⣄⠀⠀⠀⠀ from full hp in RL, please nerf!


Reply to: