| Message ID | 20230724123529.288581-1-zboszor@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | rpm: Install and/or tweak rpm macros file to make rpmbuild work | expand |
On Mon, 24 Jul 2023 at 15:51, Zoltan Boszormenyi <zboszor@gmail.com> wrote: > + sed -i \ > + -e "s:^%_lib\t.*$:%_lib\t${baselib}:" \ > + -e "s:^%_libdir\t.*$:%_libdir\t${libdir}:" \ > + ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux/macros Can this be refactored to avoid sed please? This is both difficult or impossible to understand, and is prone to silent regressions. Alex
On Mon, 24 Jul 2023 at 16:02, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > + sed -i \ > > + -e "s:^%_lib\t.*$:%_lib\t${baselib}:" \ > > + -e "s:^%_libdir\t.*$:%_libdir\t${libdir}:" \ > > + ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux/macros > > Can this be refactored to avoid sed please? This is both difficult or > impossible to understand, and is prone to silent regressions. What I mean is, can the file be generated in the first place with the correct values? Alex
2023. 07. 24. 16:03 keltezéssel, Alexander Kanavin írta: > On Mon, 24 Jul 2023 at 16:02, Alexander Kanavin <alex.kanavin@gmail.com> wrote: >>> + sed -i \ >>> + -e "s:^%_lib\t.*$:%_lib\t${baselib}:" \ >>> + -e "s:^%_libdir\t.*$:%_libdir\t${libdir}:" \ >>> + ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux/macros >> Can this be refactored to avoid sed please? This is both difficult or >> impossible to understand, and is prone to silent regressions. > What I mean is, can the file be generated in the first place with the > correct values? I'll rework it using a template file. Still, sed would be used, but in a more readable fashion. Will this work for you?
On Mon, 24 Jul 2023 at 16:59, Böszörményi Zoltán <zboszor@gmail.com> wrote: > I'll rework it using a template file. > Still, sed would be used, but in a more readable fashion. > > Will this work for you? What would be preferred is a patch to the source code, and if we can submit it upstream, that'd be even better. Alex
On Mon, 2023-07-24 at 14:35 +0200, Zoltan Boszormenyi wrote: > Some BSP architecture builds (e.g. genericx86-64 or anything from > meta-intel) don't have their /usr/lib/rpm/platform/<arch>-linux > directories. This causes rpmbuild fail on the target machine. > > Use ${SDK_ARCH}-linux as the base arch which likely exists in > /usr/lib/rpm/platform and clone it as ${MACHINE_ARCH}-linux. > > Also, fix %_lib and %_libdir in the new cloned platform directory > to use ${baselib} and ${libdir} so the RPM package contents will > be correct for library packages. > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> > --- > meta/recipes-devtools/rpm/rpm_4.18.1.bb | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.1.bb b/meta/recipes-devtools/rpm/rpm_4.18.1.bb > index 95a9e92f96..21f0127561 100644 > --- a/meta/recipes-devtools/rpm/rpm_4.18.1.bb > +++ b/meta/recipes-devtools/rpm/rpm_4.18.1.bb > @@ -131,7 +131,20 @@ do_install:append:class-nativesdk() { > # Rpm's make install creates var/tmp which clashes with base-files packaging > do_install:append:class-target() { > rm -rf ${D}/var > + > + if [ -d "${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux" ]; then > + if [ ! -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then > + cp -r ${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux > + fi > + fi SDK_ARCH should not be referenced outside of nativesdk recipes. This reference is almost certainly incorrect as it would make the target recipe dependent on the value of SDKMACHINE. Cheers, Richard
2023. 07. 24. 17:59 keltezéssel, Richard Purdie írta: > On Mon, 2023-07-24 at 14:35 +0200, Zoltan Boszormenyi wrote: >> Some BSP architecture builds (e.g. genericx86-64 or anything from >> meta-intel) don't have their /usr/lib/rpm/platform/<arch>-linux >> directories. This causes rpmbuild fail on the target machine. >> >> Use ${SDK_ARCH}-linux as the base arch which likely exists in >> /usr/lib/rpm/platform and clone it as ${MACHINE_ARCH}-linux. >> >> Also, fix %_lib and %_libdir in the new cloned platform directory >> to use ${baselib} and ${libdir} so the RPM package contents will >> be correct for library packages. >> >> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >> --- >> meta/recipes-devtools/rpm/rpm_4.18.1.bb | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/meta/recipes-devtools/rpm/rpm_4.18.1.bb b/meta/recipes-devtools/rpm/rpm_4.18.1.bb >> index 95a9e92f96..21f0127561 100644 >> --- a/meta/recipes-devtools/rpm/rpm_4.18.1.bb >> +++ b/meta/recipes-devtools/rpm/rpm_4.18.1.bb >> @@ -131,7 +131,20 @@ do_install:append:class-nativesdk() { >> # Rpm's make install creates var/tmp which clashes with base-files packaging >> do_install:append:class-target() { >> rm -rf ${D}/var >> + >> + if [ -d "${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux" ]; then >> + if [ ! -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then >> + cp -r ${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux >> + fi >> + fi > > SDK_ARCH should not be referenced outside of nativesdk recipes. This > reference is almost certainly incorrect as it would make the target > recipe dependent on the value of SDKMACHINE. Please advise what setting should be used instead. MACHINE_ARCH is what ends up in /etc/rpm/platform. TARGET_ARCH is not available in Honister but SDK_ARCH is. Suggest a common setting that can be used in both older and newer Yocto versions that has the base arch name and is usable for target builds. Thanks.
On Mon, 2023-07-24 at 20:13 +0200, Böszörményi Zoltán wrote: > 2023. 07. 24. 17:59 keltezéssel, Richard Purdie írta: > > On Mon, 2023-07-24 at 14:35 +0200, Zoltan Boszormenyi wrote: > > > Some BSP architecture builds (e.g. genericx86-64 or anything from > > > meta-intel) don't have their /usr/lib/rpm/platform/<arch>-linux > > > directories. This causes rpmbuild fail on the target machine. > > > > > > Use ${SDK_ARCH}-linux as the base arch which likely exists in > > > /usr/lib/rpm/platform and clone it as ${MACHINE_ARCH}-linux. > > > > > > Also, fix %_lib and %_libdir in the new cloned platform directory > > > to use ${baselib} and ${libdir} so the RPM package contents will > > > be correct for library packages. > > > > > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> > > > --- > > > meta/recipes-devtools/rpm/rpm_4.18.1.bb | 13 +++++++++++++ > > > 1 file changed, 13 insertions(+) > > > > > > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.1.bb b/meta/recipes-devtools/rpm/rpm_4.18.1.bb > > > index 95a9e92f96..21f0127561 100644 > > > --- a/meta/recipes-devtools/rpm/rpm_4.18.1.bb > > > +++ b/meta/recipes-devtools/rpm/rpm_4.18.1.bb > > > @@ -131,7 +131,20 @@ do_install:append:class-nativesdk() { > > > # Rpm's make install creates var/tmp which clashes with base-files packaging > > > do_install:append:class-target() { > > > rm -rf ${D}/var > > > + > > > + if [ -d "${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux" ]; then > > > + if [ ! -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then > > > + cp -r ${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux > > > + fi > > > + fi > > > > SDK_ARCH should not be referenced outside of nativesdk recipes. This > > reference is almost certainly incorrect as it would make the target > > recipe dependent on the value of SDKMACHINE. > > Please advise what setting should be used instead. > > MACHINE_ARCH is what ends up in /etc/rpm/platform. > TARGET_ARCH is not available in Honister but SDK_ARCH is. > > Suggest a common setting that can be used in both older and > newer Yocto versions that has the base arch name and is > usable for target builds. I'm afraid I don't understand the problem you're running into from your description so I don't know how to answer that. TARGET_ARCH has been around in OE for many years so I'd be surprised it is unavailable in honister though. I do know that SDK_ARCH is incorrect here though. To prove what I'm saying, try setting SDKMACHINE = "i686" and then check the value of SDK_ARCH compared to when SDKMACHINE = "x86_64" (or "aarch64"). Cheers, Richard
2023. 07. 24. 22:16 keltezéssel, Richard Purdie írta: > On Mon, 2023-07-24 at 20:13 +0200, Böszörményi Zoltán wrote: >> 2023. 07. 24. 17:59 keltezéssel, Richard Purdie írta: >>> On Mon, 2023-07-24 at 14:35 +0200, Zoltan Boszormenyi wrote: >>>> Some BSP architecture builds (e.g. genericx86-64 or anything from >>>> meta-intel) don't have their /usr/lib/rpm/platform/<arch>-linux >>>> directories. This causes rpmbuild fail on the target machine. >>>> >>>> Use ${SDK_ARCH}-linux as the base arch which likely exists in >>>> /usr/lib/rpm/platform and clone it as ${MACHINE_ARCH}-linux. >>>> >>>> Also, fix %_lib and %_libdir in the new cloned platform directory >>>> to use ${baselib} and ${libdir} so the RPM package contents will >>>> be correct for library packages. >>>> >>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>> --- >>>> meta/recipes-devtools/rpm/rpm_4.18.1.bb | 13 +++++++++++++ >>>> 1 file changed, 13 insertions(+) >>>> >>>> diff --git a/meta/recipes-devtools/rpm/rpm_4.18.1.bb b/meta/recipes-devtools/rpm/rpm_4.18.1.bb >>>> index 95a9e92f96..21f0127561 100644 >>>> --- a/meta/recipes-devtools/rpm/rpm_4.18.1.bb >>>> +++ b/meta/recipes-devtools/rpm/rpm_4.18.1.bb >>>> @@ -131,7 +131,20 @@ do_install:append:class-nativesdk() { >>>> # Rpm's make install creates var/tmp which clashes with base-files packaging >>>> do_install:append:class-target() { >>>> rm -rf ${D}/var >>>> + >>>> + if [ -d "${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux" ]; then >>>> + if [ ! -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then >>>> + cp -r ${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux >>>> + fi >>>> + fi >>> SDK_ARCH should not be referenced outside of nativesdk recipes. This >>> reference is almost certainly incorrect as it would make the target >>> recipe dependent on the value of SDKMACHINE. >> Please advise what setting should be used instead. >> >> MACHINE_ARCH is what ends up in /etc/rpm/platform. >> TARGET_ARCH is not available in Honister but SDK_ARCH is. >> >> Suggest a common setting that can be used in both older and >> newer Yocto versions that has the base arch name and is >> usable for target builds. > I'm afraid I don't understand the problem you're running into from your > description so I don't know how to answer that. TARGET_ARCH has been > around in OE for many years so I'd be surprised it is unavailable in > honister though. I usually verify variable settings via "bitbake -e packagename" and what I can see is that this: bitbake -e rpm >rpm-vars.txt 2>&1 grep TARGET_ARCH rpm-vars.txt shows TRANSLATED_TARGET_ARCH on Honister with TARGET_ARCH missing. Can I still use TARGET_ARCH in the rpm recipe on this old Yocto version? > I do know that SDK_ARCH is incorrect here though. This is why I asked to suggest the correct setting name. > To prove what I'm > saying, try setting SDKMACHINE = "i686" and then check the value of > SDK_ARCH compared to when SDKMACHINE = "x86_64" (or "aarch64"). > > Cheers, > > Richard
2023. 07. 24. 17:20 keltezéssel, Alexander Kanavin írta: > On Mon, 24 Jul 2023 at 16:59, Böszörményi Zoltán <zboszor@gmail.com> wrote: >> I'll rework it using a template file. >> Still, sed would be used, but in a more readable fashion. >> >> Will this work for you? > What would be preferred is a patch to the source code, and if we can > submit it upstream, that'd be even better. 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.
On Tue, 2023-07-25 at 12:24 +0200, Böszörményi Zoltán wrote: > 2023. 07. 24. 22:16 keltezéssel, Richard Purdie írta: > > On Mon, 2023-07-24 at 20:13 +0200, Böszörményi Zoltán wrote: > > > 2023. 07. 24. 17:59 keltezéssel, Richard Purdie írta: > > > > On Mon, 2023-07-24 at 14:35 +0200, Zoltan Boszormenyi wrote: > > > > > Some BSP architecture builds (e.g. genericx86-64 or anything from > > > > > meta-intel) don't have their /usr/lib/rpm/platform/<arch>-linux > > > > > directories. This causes rpmbuild fail on the target machine. > > > > > > > > > > Use ${SDK_ARCH}-linux as the base arch which likely exists in > > > > > /usr/lib/rpm/platform and clone it as ${MACHINE_ARCH}-linux. > > > > > > > > > > Also, fix %_lib and %_libdir in the new cloned platform directory > > > > > to use ${baselib} and ${libdir} so the RPM package contents will > > > > > be correct for library packages. > > > > > > > > > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> > > > > > --- > > > > > meta/recipes-devtools/rpm/rpm_4.18.1.bb | 13 +++++++++++++ > > > > > 1 file changed, 13 insertions(+) > > > > > > > > > > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.1.bb b/meta/recipes-devtools/rpm/rpm_4.18.1.bb > > > > > index 95a9e92f96..21f0127561 100644 > > > > > --- a/meta/recipes-devtools/rpm/rpm_4.18.1.bb > > > > > +++ b/meta/recipes-devtools/rpm/rpm_4.18.1.bb > > > > > @@ -131,7 +131,20 @@ do_install:append:class-nativesdk() { > > > > > # Rpm's make install creates var/tmp which clashes with base-files packaging > > > > > do_install:append:class-target() { > > > > > rm -rf ${D}/var > > > > > + > > > > > + if [ -d "${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux" ]; then > > > > > + if [ ! -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then > > > > > + cp -r ${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux > > > > > + fi > > > > > + fi > > > > SDK_ARCH should not be referenced outside of nativesdk recipes. This > > > > reference is almost certainly incorrect as it would make the target > > > > recipe dependent on the value of SDKMACHINE. > > > Please advise what setting should be used instead. > > > > > > MACHINE_ARCH is what ends up in /etc/rpm/platform. > > > TARGET_ARCH is not available in Honister but SDK_ARCH is. > > > > > > Suggest a common setting that can be used in both older and > > > newer Yocto versions that has the base arch name and is > > > usable for target builds. > > I'm afraid I don't understand the problem you're running into from your > > description so I don't know how to answer that. TARGET_ARCH has been > > around in OE for many years so I'd be surprised it is unavailable in > > honister though. > > I usually verify variable settings via "bitbake -e packagename" > and what I can see is that this: > > bitbake -e rpm >rpm-vars.txt 2>&1 > grep TARGET_ARCH rpm-vars.txt > > shows TRANSLATED_TARGET_ARCH on Honister with TARGET_ARCH missing. > Can I still use TARGET_ARCH in the rpm recipe on this old Yocto version? In honister there is this: $ grep TARGET_ARCH.*export * -R meta/conf/bitbake.conf:# Make sure TARGET_ARCH isn't exported meta/conf/bitbake.conf:TARGET_ARCH[unexport] = "1" which is why it doesn't show up in bitbake -e, the variable does exist though. Cheers, Richard
On Tue, 25 Jul 2023 at 12:27, Böszörményi Zoltán <zboszor@gmail.com> 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. Alex
2023. 07. 25. 12:30 keltezéssel, Alexander Kanavin írta: > On Tue, 25 Jul 2023 at 12:27, Böszörményi Zoltán <zboszor@gmail.com> 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. 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.
2023. 07. 25. 12:29 keltezéssel, Richard Purdie írta: > On Tue, 2023-07-25 at 12:24 +0200, Böszörményi Zoltán wrote: >> 2023. 07. 24. 22:16 keltezéssel, Richard Purdie írta: >>> On Mon, 2023-07-24 at 20:13 +0200, Böszörményi Zoltán wrote: >>>> 2023. 07. 24. 17:59 keltezéssel, Richard Purdie írta: >>>>> On Mon, 2023-07-24 at 14:35 +0200, Zoltan Boszormenyi wrote: >>>>>> Some BSP architecture builds (e.g. genericx86-64 or anything from >>>>>> meta-intel) don't have their /usr/lib/rpm/platform/<arch>-linux >>>>>> directories. This causes rpmbuild fail on the target machine. >>>>>> >>>>>> Use ${SDK_ARCH}-linux as the base arch which likely exists in >>>>>> /usr/lib/rpm/platform and clone it as ${MACHINE_ARCH}-linux. >>>>>> >>>>>> Also, fix %_lib and %_libdir in the new cloned platform directory >>>>>> to use ${baselib} and ${libdir} so the RPM package contents will >>>>>> be correct for library packages. >>>>>> >>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>>>> --- >>>>>> meta/recipes-devtools/rpm/rpm_4.18.1.bb | 13 +++++++++++++ >>>>>> 1 file changed, 13 insertions(+) >>>>>> >>>>>> diff --git a/meta/recipes-devtools/rpm/rpm_4.18.1.bb b/meta/recipes-devtools/rpm/rpm_4.18.1.bb >>>>>> index 95a9e92f96..21f0127561 100644 >>>>>> --- a/meta/recipes-devtools/rpm/rpm_4.18.1.bb >>>>>> +++ b/meta/recipes-devtools/rpm/rpm_4.18.1.bb >>>>>> @@ -131,7 +131,20 @@ do_install:append:class-nativesdk() { >>>>>> # Rpm's make install creates var/tmp which clashes with base-files packaging >>>>>> do_install:append:class-target() { >>>>>> rm -rf ${D}/var >>>>>> + >>>>>> + if [ -d "${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux" ]; then >>>>>> + if [ ! -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then >>>>>> + cp -r ${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux >>>>>> + fi >>>>>> + fi >>>>> SDK_ARCH should not be referenced outside of nativesdk recipes. This >>>>> reference is almost certainly incorrect as it would make the target >>>>> recipe dependent on the value of SDKMACHINE. >>>> Please advise what setting should be used instead. >>>> >>>> MACHINE_ARCH is what ends up in /etc/rpm/platform. >>>> TARGET_ARCH is not available in Honister but SDK_ARCH is. >>>> >>>> Suggest a common setting that can be used in both older and >>>> newer Yocto versions that has the base arch name and is >>>> usable for target builds. >>> I'm afraid I don't understand the problem you're running into from your >>> description so I don't know how to answer that. TARGET_ARCH has been >>> around in OE for many years so I'd be surprised it is unavailable in >>> honister though. >> I usually verify variable settings via "bitbake -e packagename" >> and what I can see is that this: >> >> bitbake -e rpm >rpm-vars.txt 2>&1 >> grep TARGET_ARCH rpm-vars.txt >> >> shows TRANSLATED_TARGET_ARCH on Honister with TARGET_ARCH missing. >> Can I still use TARGET_ARCH in the rpm recipe on this old Yocto version? > In honister there is this: > > $ grep TARGET_ARCH.*export * -R > meta/conf/bitbake.conf:# Make sure TARGET_ARCH isn't exported > meta/conf/bitbake.conf:TARGET_ARCH[unexport] = "1" > > which is why it doesn't show up in bitbake -e, the variable does exist > though. Thanks! > > Cheers, > > Richard
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 <zboszor@gmail.com> 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?
2023. 07. 25. 12:30 keltezéssel, Alexander Kanavin írta: > On Tue, 25 Jul 2023 at 12:27, Böszörményi Zoltán <zboszor@gmail.com> 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. I sent the recipe change so you can see the complete picture. FWIW, I was able to build a complete image using this (no problems during do_rootfs or anywhere), and rpmbuild works out of the box on the target system.
diff --git a/meta/recipes-devtools/rpm/rpm_4.18.1.bb b/meta/recipes-devtools/rpm/rpm_4.18.1.bb index 95a9e92f96..21f0127561 100644 --- a/meta/recipes-devtools/rpm/rpm_4.18.1.bb +++ b/meta/recipes-devtools/rpm/rpm_4.18.1.bb @@ -131,7 +131,20 @@ do_install:append:class-nativesdk() { # Rpm's make install creates var/tmp which clashes with base-files packaging do_install:append:class-target() { rm -rf ${D}/var + + if [ -d "${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux" ]; then + if [ ! -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then + cp -r ${D}${prefix}/lib/rpm/platform/${SDK_ARCH}-linux ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux + fi + fi + if [ -d ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux ]; then + sed -i \ + -e "s:^%_lib\t.*$:%_lib\t${baselib}:" \ + -e "s:^%_libdir\t.*$:%_libdir\t${libdir}:" \ + ${D}${prefix}/lib/rpm/platform/${MACHINE_ARCH}-linux/macros + fi } + do_install:append:class-nativesdk() { rm -rf ${D}${SDKPATHNATIVE}/var # Ensure find-debuginfo is located correctly inside SDK
Some BSP architecture builds (e.g. genericx86-64 or anything from meta-intel) don't have their /usr/lib/rpm/platform/<arch>-linux directories. This causes rpmbuild fail on the target machine. Use ${SDK_ARCH}-linux as the base arch which likely exists in /usr/lib/rpm/platform and clone it as ${MACHINE_ARCH}-linux. Also, fix %_lib and %_libdir in the new cloned platform directory to use ${baselib} and ${libdir} so the RPM package contents will be correct for library packages. Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> --- meta/recipes-devtools/rpm/rpm_4.18.1.bb | 13 +++++++++++++ 1 file changed, 13 insertions(+)