> This is also a valid approach. This is the first alternative proposal > which makes me say "hmm, this would also work". It is possibly even > simpler than setting the $PATH. A very small disadvantage is that the > wrapper would need to do its work every time the binary is called. > But the wrapper could be trivially implemented in shell or it could be > a compiled binary, making the wrapper very cheap. > > Hmm, what do other people think?
With my computer user hat on, I would much prefer this approach. If the supposed "dozen" of relevant packages can be built with several binaries variants, then let's pack them all in the same RPM and use this mechanism. I'm sure that if successful it would extend to more packages, including packages on the critical path. I'm fine with that eventual outcome with this scheme. This way, if I ever need to take my drive out of a fried laptop and USB-boot from it on my spare laptop from 2013, then I'm not painting myself into a corner with binaries too recent for that hardware. I was happy to be able to do that last summer, and hope to still be able to in the future (but also hope not to ever need it again). And yes, Fedora (Xfce) works just fine on that decade-old laptop. For a wrapper I would be in favor of a shell script, it makes things much easier to understand as an end user, and it can be installed once, for example: > ls -l /usr/bin/cp > lrwxrwxrwx. 1 root root 26 Jan 1 00:00 /usr/bin/cp -> > /usr/libexec/uarch-exec.sh On the condition of course that the generic binary is always present, which shouldn't be difficult if all variants are in the same package in the first place. In theory there should be less moving parts, but the difference between theory and reality... My 2 cents -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
