Re: Building two conflicting binaries from the same source
On Tuesday, 8 November 2022 09:43:40 GMT Richard W.M. Jones wrote: > On Fri, Nov 04, 2022 at 01:44:41PM +0100, Petr Menšík wrote: > > > 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. > > > I think this is right. In particular you cannot assume that "the > hardware" is a thing which remains stable for the lifetime of a Fedora > install. > > Sure, if you install Fedora on your laptop then the hardware is > unlikely to change. But if you install Fedora on a VM then it can be > moved and booted on a VM with different (virtual) hardware. And > there's also the template case where someone prepares a disk image on > one set of hardware (maybe virtual or physical) and then the disk > image is used as a template to clone multiple systems from. > > Having autodetection at run time deals with this, having different > hardware-specific RPMs installed does not. > > Rich. > Even on a laptop or desktop, hardware may change underneath you. For example, early Intel Alder Lake CPUs would expose AVX-512 in CPUID if you turned off all the Efficiency cores, and just left the Performance cores; a later microcode update stopped this working, and force-disabled AVX-512. There's also been efforts to bring mainframe-style "upgradeable silicon" down to the consumer market, like the Intel Upgrade Service[0]. For laptops, this has great appeal to manufacturers - you can build a bunch of machines with a soldered down Celeron CPU, and upgrade them to Core i3/i5/i7 during pre-sale provisioning, allowing you to reduce your stock needs. Once you can do that, why not also sell the upgrade keys to people who bought the cheap Celeron, making a profit on up-selling them to the i7 later? [0] https://en.wikipedia.org/wiki/Intel_Upgrade_Service -- Simon Farnsworth ___ 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
Re: Building two conflicting binaries from the same source
On Fri, Nov 04, 2022 at 01:44:41PM +0100, Petr Menšík wrote: > 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. I think this is right. In particular you cannot assume that "the hardware" is a thing which remains stable for the lifetime of a Fedora install. Sure, if you install Fedora on your laptop then the hardware is unlikely to change. But if you install Fedora on a VM then it can be moved and booted on a VM with different (virtual) hardware. And there's also the template case where someone prepares a disk image on one set of hardware (maybe virtual or physical) and then the disk image is used as a template to clone multiple systems from. Having autodetection at run time deals with this, having different hardware-specific RPMs installed does not. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
Re: Building two conflicting binaries from the same source
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
Re: Building two conflicting binaries from the same source
Possibly in one of the future versions. I am not even sure at this point how well (if at all) glamor support works with xorgxrdp. -- Bojan -Original Message- From: Hans de Goede To: Development discussions related to Fedora Cc: Bojan Smojver Subject: Re: Building two conflicting binaries from the same source Date: 04/11/22 19:45:43 Maybe the rpath tricks + making the actual lib (or binary) a link to /run/foo and then have a udev rule create /run/foo to point to the right version depending on the hw it is running on might be useful for you too ? ___ 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
Re: Building two conflicting binaries from the same source
It was for packaging xorgxrdp with glamor support. Submitted to bodhi now, so all good. -- Bojan 4 Nov 2022 7:38:17 pm Hans de Goede : Hi, 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. Is this perhaps for the Intel IPU6 camera support userspace bits? If yes I'm working on packaging those (for rpmfusion since parts are closed source) and I have a plan how to deal with them. If no, then please ignore this email :) (just making sure that if the answer is yes we can coordinate / avoid doing double work) Regards, Hans ___ 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
Re: Building two conflicting binaries from the same source
Hi Again, 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. I just realized that my IPU6 plans might be useful for you regardless of if that is your use case too. So the IPU6 userspace bits consist of a bunch of closed source .so files in 2 different variants for 2 different hw generations. Against this a libcamerahal.so gets build, which build is also hw generation specific. And then there is a gstreamer-1.0 plugin which consumes libcamerahal.so, but which build is not hw generation specific (AFAICT, still need to verify this). I want support for both hw generations to be installed at the same time, rather then have 2 conflicting subpackages because I don't want users to have to know which generation they exactly have. And I want this to work with a read-only /usr. So here is what I've come up with (from my own notes, so might be a bit cryptic): -Rename libcamerahal.so to libcamerahal-ipu6.so and patch in a rpath to /usr/lib64/ipu6 for the other libs, then make libcamerahal.so a symlink to /run/libcamerahal.so which is a symlink to the one we actual want; and have udev-rules dynamically set /run/libcamerahal.so symlink -See: https://github.com/Linuxbrew/legacy-linuxbrew/issues/7 for ideas to set the rpath -Needs something to allow building on non IPU6 systems -> hack .pc file to just always point to the plain (tgl) ipu6 version -Patch hal s|share/defaults/etc|share/defaults/etc/ipu6| for different etc dirs per IPU6 version Maybe the rpath tricks + making the actual lib (or binary) a link to /run/foo and then have a udev rule create /run/foo to point to the right version depending on the hw it is running on might be useful for you too ? Regards, Hans ___ 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
Re: Building two conflicting binaries from the same source
Hi, 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. Is this perhaps for the Intel IPU6 camera support userspace bits? If yes I'm working on packaging those (for rpmfusion since parts are closed source) and I have a plan how to deal with them. If no, then please ignore this email :) (just making sure that if the answer is yes we can coordinate / avoid doing double work) Regards, Hans ___ 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
Re: Building two conflicting binaries from the same source
On 03/11/2022 21:31, Bojan Smojver via devel wrote:
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.
Use different build directories, then rename result in %install.
One subpackage will have %{_bindir}/%{name}-foo, another -
%{_bindir}/%{name}-bar.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
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
Re: Building two conflicting binaries from the same source
On 03/11/2022 22:14, Bojan Smojver via devel wrote: PS. I am aware of the alternatives approach, but looking to see whether there is something that rpm specs have natively for this. You can't use alternatives on immutable Fedora versions. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
Re: Building two conflicting binaries from the same source
Collections can also help manage this:
https://www.softwarecollections.org/en/
On 11/4/22 01:21, Bojan Smojver via devel wrote:
Thank you!
--
Bojan
4 Nov 2022 8:48:25 am Florian Weimer :
* Bojan Smojver via devel:
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?
See tests/data/SPECS/test-subpackages-pathpostfixes.spec in the RPM
source tree:
| Name: test
| […]
| %description
| %{summary}.
|
| %package test2
| RemovePathPostfixes: .foobar
| Summary: Test2.
| %description test2
| […]
| %files
| /bin/hello
|
| %files test2
| /bin/hello.foobar
| […]
The key enabler is RemovePathPostfixes.
Thanks,
Florian
___
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
___
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
Re: Building two conflicting binaries from the same source
Thank you!
--
Bojan
4 Nov 2022 8:48:25 am Florian Weimer :
* Bojan Smojver via devel:
> 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?
See tests/data/SPECS/test-subpackages-pathpostfixes.spec in the RPM
source tree:
| Name: test
| […]
| %description
| %{summary}.
|
| %package test2
| RemovePathPostfixes: .foobar
| Summary: Test2.
| %description test2
| […]
| %files
| /bin/hello
|
| %files test2
| /bin/hello.foobar
| […]
The key enabler is RemovePathPostfixes.
Thanks,
Florian
___
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
Re: Building two conflicting binaries from the same source
* Bojan Smojver via devel:
> 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?
See tests/data/SPECS/test-subpackages-pathpostfixes.spec in the RPM
source tree:
| Name: test
| […]
| %description
| %{summary}.
|
| %package test2
| RemovePathPostfixes: .foobar
| Summary: Test2.
| %description test2
| […]
| %files
| /bin/hello
|
| %files test2
| /bin/hello.foobar
| […]
The key enabler is RemovePathPostfixes.
Thanks,
Florian
___
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
Re: Building two conflicting binaries from the same source
Cool, thank you! I think this is exactly what I was looking for (unsuccessfully). -- Bojan ___ 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
Re: Building two conflicting binaries from the same source
Hello, Bojan.
The only way I know is to utilise the "RemovePathPostfixes" tag for this, e.g:
> %package gtk3
> RemovePathPostfixes: .gtk3
>
> %package qt
> RemovePathPostfixes: .qt
>
> %files gtk3
> %{_bindir}/%{name}.gtk3
>
> %files qt5
> %{_bindir}/%{name}.qt5
Then, you just need to rename the binaries appropriately during %install.
If you want to read more, I originally learned about it from the following post:
https://www.pixelbeat.org/docs/conflicting-rpms.html
A.FI.
___
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
Re: Building two conflicting binaries from the same source
PS. I am aware of the alternatives approach, but looking to see whether there is something that rpm specs have natively for this. -- Bojan 4 Nov 2022 7:31:14 am Bojan Smojver : 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 ___ 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
Building two conflicting binaries from the same source
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 ___ 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
