I think the need to find such attempts is a clear indication
there is something wrong with the design of current
implementation.
If there are binaries with different build results, I think some
code should be refactored out of the binary itself. The common
parts can remain, but hardware specific parts should be moved to
dynamically loaded *.so files. The correct files should be loaded
depending on hardware found on the system. If auto-detection is
wrong, manual configuration via configuration file should be used
instead.
Are we talking about shared library or executable binary? I think executable binary might use just shell wrapper doing the detection and running correct implementation build. I admit it requires non-trivial changes, but it seems to me they would be required sooner or later.
Just my 2 cents.
Petr
This may be a trivial question, but my friend Google is not showing me any obvious answers, so I will ask here at my own peril.
Say one needs to configure and build the same source with two (or more) different sets of options that generate different binary RPMs, but which have files in exactly the same place. This is to support different hardware. The end result would be mutually conflicting binary packages that users then install etc.
Sure, it is easy enough to configure/build repeatedly and stash the results into non-conflicting paths of buildroot, but how does one then package this in %files sections into exactly the same paths?
If there is an example floating somewhere, that would be very useful.
Thanks,
--
Bojan
-- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________ 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