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
