On 01/06/2017 08:04 AM, Jakub Jelinek wrote: > On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote: >> On 01/05/2017 02:08 PM, Stephen Gallagher wrote: >> [snip] >>> == multi-arch layout == >>> * Moving the locations of all of the system libraries would potentially still >>> break third-party applications that were compiled to expect libraries to be in >>> the /usr/lib[64] paths. This would be a similar problem to the UsrMove change >>> and would likely be solved the same way; by maintaining symlinks in the old >>> locations for some reasonable migration period. Given the enormous number of >>> packages involved and the fact that it's not a simple directory rename, we may >>> need to add a hack into rpmbuild to automatically generate these symlinks in the >>> old location. >>> >>> * Switching to this layout might give a false (or possibly accurate, in some >>> cases) impression that one could expect Debian/Ubuntu packages to function "out >>> of the box" on Fedora (if using something like Alien). Education is key here. >> [snip] >> >> For anyone who isn't familiar with this topic, you might find Debian's >> documentation useful: >> >> https://wiki.debian.org/Multiarch >> >> One could take it a step further and actually have target triplets the >> convey OS version of the libraries instead of the generic "-redhat-linux" >> part of the tuple. With a little rpath abuse apps compiled for F25 could >> find their shared libraries in an F25 specific directory and multiple >> versions of the same package could be installed at the same time, for >> different OS versions. This goes beyond Fedora, too: apps compiled for >> Debian could find their shared libraries in a Debian specific directory, >> even though it's a Fedora system that is booted. A lot of fiddly details >> and hand waving go here, but the end result would be really useful. > > Noo! Debian Multiarch is FHS incompatible, too ugly to live with and > doesn't bring benefits, it is just different. > Please don't introduce this into Fedora. I added it to this list because it came up several times in the earlier thread. I'm not sold on it. I'm CCing the people who suggested it directly to ask them to chime in with what advantages they feel it would provide. As to the FHS? It's a standard in the same way that CIM is a standard: it's a great starting point and we try to stay as close as possible to it, but if it doesn't meet our needs, we'll work around it.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
