Wookey <woo...@wookware.org> wrote: > +++ Christian Seiler [2016-05-07 16:14 +0200]: > > On 05/07/2016 03:59 PM, Geert Stappers wrote: > > > I now have a better idea _why_ a sse-suport package. > > I do think that this sort of ISA-level checking would be best done via > dpkg and package metadata, although this sse-support mechanism will > obviously work. i.e the cpontrol file says what ISA features are > wanted and dpkg can not install it if those HWCAPS are not available > (or indeed install alternate versions that will work if they are > available). > > We worked up a prototype spec for this a couple of years ago (at the > bootstrap sprint), but it needs the namespace and granularity fleshing > out: what is the set of HWCAPS listed in each package, what is > presumed to be 'base' that we don't list individually, and so on.
I'd love to see this integrated with dpkg multiarch support. That way, for instance, specific packages could provide optimized versions for specific target CPU features. I think we'd need three things to make that happen: 1) Support in dpkg multiarch to understand "compatible" architectures that can satisfy each others' dependencies (e.g. a dependency on libfoo1:amd64 is satisfied by libfoo1:amd64+avx2, and vice versa). 2) Support for synthesizing such architectures in a canonical way from a set of CPU features, so that every combination of CPU features doesn't need its own unique architecture name (we don't want architecture names like "amd64+sse4+avx2+rdrand", even though a package might need that set of features). 3) Support for detecting available CPU features, as you mentioned above, to not even attempt to install a package that requires unavailable CPU features. Optionally, we could also detect if the set of CPU features has changed incompatibly. For instance, if you move your Debian filesystem to a system without some features that you have installed packages depending on, it'd be nice to handle that as gracefully as possible. - Josh Triplett
