Re: Building two conflicting binaries from the same source

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux