On Tue, Jan 16, 2024 at 2:43 PM Dridi Boukelmoune <dridi.boukelmoune@xxxxxxxxx> wrote: > > > 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. But ... you would be able to do this if the proposal was implemented as-is, as well? The "non-optimized" variant would still be installed, and PATH would be set appropriately to fall back to it if you stick the hard drive into an old machine (unless I misunderstand the proposal, or your argument here). Just to give my 2¢ here as well, I was skeptical about the "systemd sets the $PATH appropriately for the hardware it's booting on", but I actually like that approach now. Using symbolic links smells too much like using alternatives, and those have always been a bit brittle. Fabio -- _______________________________________________ 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
