2023. 07. 25. 12:42 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org írta:
2023. 07. 25. 12:30 keltezéssel, Alexander Kanavin írta:On Tue, 25 Jul 2023 at 12:27, Böszörményi Zoltán <[email protected]> wrote:I have a working recipe change based on https://github.com/rpm-software-management/rpm/pull/2579 (for 4.18.x) https://github.com/rpm-software-management/rpm/pull/2580 (for 4.19.x)I will send it soon.I'd want to see what rpm upstream says. Maybe we're doing the whole platform macro thing wrongly.Hm. Maybe using the BSP name as the platform name is the problem.
Maybe it's not that much of a problem.
As far as I can see, kernel packages and a few others are built
using ${MACHINE_ARCH}.rpm and are put into different
subdirectories in a package repository. If everything was
built using ${TARGET_ARCH}.rpm, different BSPs that require
different kernels but otherwise use identical packages wouldn't
be able to use a common repositories.
If the project intends to keep this feature, then something
like the patch I posted on github is needed.
FWIW, on Fedora, there is no /etc/rpm/platform and binary packages simply use .x86_64.rpm or .i686.rpm suffixes. Apparently, rpmbuild can deduce the platform without help. After removing /etc/rpm/platform, rpmbuild will generate an .x86_64.rpm for me.
And this won't allow building a BSP specific kernel package in the sense that the package would be installable on a different BSP With the patch I posted on github, any package built on a specific machine will use the BSP specific file name suffix and maybe it won't be installable on a compatible TARGET_ARCH machine. Catch-22?
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184837): https://lists.openembedded.org/g/openembedded-core/message/184837 Mute This Topic: https://lists.openembedded.org/mt/100328070/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
