On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote:
> The hardware capabilities system works fine upstream, but doesn't work
> for us because:
> 1) we want to be able to upgrade major upstream version online (as
> opposed to fedora for example)
> 2) we ship the optimized libraries in a different package
> 
> The various libc librairies need to have the same version at any time,
> this is especially true for ld.so vs libc.so. As we do not upgrade the
> default libc and the optimized one exactly at the same time (they are in
> different packages), we upgrade first the default libc and then we have
> the Debian specific nohwcap mechanism to prevent using the optimize
> library until it has also been upgraded.
> 
> One solution for this would be to ship the optimized library in the same
> package as the default library. Now this is not acceptable for embedded
> systems as they might not need that library and can't remove it. This is
> even more problematic if we need to add more optimized libraries. I guess
> this might be the case for arm64 as there are many new extensions in the
> pipe.

Thanks for taking the time to explain that!

I wonder if it'd make sense for libc to be a virtual package, with
functionality provided by optimized builds and dependencies satisfied
via Provides.  I don't know how well dpkg would cope with transitioning
between providers, which seems like the riskiest side of this kind of
thing.

noah

Reply via email to