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
On 11/3/22 21:31, Bojan Smojver via devel wrote:
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@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
