Note that mingw-* packages currently in Fedora install into the /usr/i686-w64-mingw32/ or /usr/x86_64-w64-mingw32/ directories.
This is a different topic but if each archful package installed
its files into a directory containing the arch name, it would
allow parallel installability without configuring dnf and possibly
make it more convenient for cross-platform development.
Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load optimized implementations of ''shared objects'' [3]. This means that packages can provide optimized libraries and they linker will be automatically load them from separate directories if appropriate. (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be nested in a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more universal.
Adding directories to the /usr sub-space generally gets bogged down into 'You are polluting my name-space' arguments which get no-where because some of the people getting angry is having to live with some 3rd party rules and regulations which stipulated how things look and will only get updated once a decade or so. [The same goes with subdirectories in /usr/bin etc where it causes similar problems.] There tends to be no 'general' case which works unless it gets 'agreed' upon by some outside of the distro body that publishes 'versioned' standards.
Checking what Debian does, they have paths such as `/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
Vít
--
Vít
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Stephen Smoogen, Red Hat AutomotiveLet us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Marián Konček
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
