From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FB03E6B24A for ; Fri, 1 Nov 2024 12:01:55 +0000 (UTC) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) by mx.groups.io with SMTP id smtpd.web11.35880.1730462510587141254 for ; Fri, 01 Nov 2024 05:01:50 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=pass (domain: t-online.de, ip: 194.25.134.81, mailfrom: f_l_k@t-online.de) Received: from fwd83.aul.t-online.de (fwd83.aul.t-online.de [10.223.144.109]) by mailout03.t-online.de (Postfix) with SMTP id 983F8A82; Fri, 1 Nov 2024 13:01:46 +0100 (CET) Received: from [192.168.178.67] ([84.154.160.37]) by fwd83.t-online.de with (TLSv1.3:TLS_AES_256_GCM_SHA384 encrypted) esmtp id 1t6qLZ-1T05Ts0; Fri, 1 Nov 2024 13:01:45 +0100 Date: Fri, 01 Nov 2024 13:03:49 +0100 From: Markus Volk Subject: Re: [oe] [meta-oe][PATCH v3] snapper: add recipe To: Martin Jansa Cc: raj.khem@gmail.com, openembedded-devel@lists.openembedded.org Message-Id: In-Reply-To: <1803C5E0EFB35EE5.1077@lists.openembedded.org> References: <20241020150843.1068181-1-raj.khem@gmail.com> <18039C488E2C1344.6352@lists.openembedded.org> <1803C5E0EFB35EE5.1077@lists.openembedded.org> X-Mailer: geary/46.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-N2j8SgYeLRs0ZvmFWPra" X-TOI-EXPURGATEID: 150726::1730462505-767FA5DD-D4886E89/0/0 CLEAN NORMAL X-TOI-MSGID: 15f21e4f-5119-4058-8567-4d2b6438f7a9 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 01 Nov 2024 12:01:55 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-devel/message/113381 --=-N2j8SgYeLRs0ZvmFWPra Content-Type: text/plain; charset=iso-8859-13; format=flowed Content-Transfer-Encoding: quoted-printable I have now set up a multilib build environment to see exactly how that=20 works. If I haven't forgotten anything, it was easier than I thought. I=20 added the following to local.conf: require conf/multilib.conf MULTILIBS =3D =E2=80=9Cmultilib:lib32=E2=80=9D DEFAULTTUNE:virtclass-multilib-lib32 =3D =E2=80=9Cx86=E2=80=9D IMAGE_INSTALL:append =3D =E2=80=9C lib32-glibc lib32-libgcc lib32-libstdc++= =20 snapper lib32-snapper=E2=80=9D Then set FILES:${PN} like this: FILES:${PN} +=3D =E2=80=9C${nonarch_libdir} ${systemd_system_unitdir}=20 ${datadir}=E2=80=9D And I was able to build core-image-minimal with both snapper and=20 lib32-snapper installed without facing any conflicts in do_rootfs On Fri, Nov 1 2024 at 07:59:35 AM +01:00:00, Markus Volk=20 wrote: > On Thu, Oct 31 2024 at 11:45:59 PM +01:00:00, Martin Jansa=20 > wrote: >> Not sure if this was worth it :). >=20 > An easy way to hack this might also be something like this ? >=20 > # Did this just for testing purpose > export nonarch_libdir =3D "/usr/lib32" >=20 > do_install:append() { > if [ ! "${libdir}" =3D "${nonarch_libdir}" ]; then mkdir=20 > ${D}${nonarch_libdir};mv ${D}${libdir}/snapper=20 > ${D}${nonarch_libdir}/snapper; fi > } >=20 >=20 > FILES:${PN} +=3D "${nonarch_libdir}/snapper ${libdir}/pam_snapper=20 > ${systemd_system_unitdir} ${libdir}/security ${datadir}" >=20 > Since I'm not building multilib, I just did an export for=20 > nonarch_libdir to have a difference here for testing. Kind of seemed=20 > to work. > The 'mkdir' command is probably only needed in my testcase, because=20 > if building multilib the ${D}${nonarch_libdir} directory is=20 > presumably already present >=20 > Not pretty but eventually less maintainance than a patch --=-N2j8SgYeLRs0ZvmFWPra Content-Type: text/html; charset=iso-8859-13 Content-Transfer-Encoding: quoted-printable
I have now set up a multilib = build environment to see exactly how that works. If I haven't forgotten any= thing, it was easier than I thought. I added the following to local.conf:
                  &nb= sp;                     &= nbsp;                    =                     &nbs= p;                     &n= bsp;             
require conf= /multilib.conf
MULTILIBS =3D =E2=80=9Cmultilib:lib32=E2=80=9D
DEFAULTTUNE:virtclass-multilib-lib32 =3D =E2=80=9Cx86=E2=80=9D
=
IMAGE_INSTALL:append =3D =E2=80=9C lib32-glibc lib32-libgcc lib32-libs= tdc++ snapper lib32-snapper=E2=80=9D

Then set FILE= S:${PN} like this:
FILES:${PN} +=3D =E2=80=9C${nonarch_libdir} ${= systemd_system_unitdir} ${datadir}=E2=80=9D

And I = was able to build core-image-minimal with both snapper and lib32-snapper in= stalled without facing any conflicts in do_rootfs



On Fri, Nov = 1 2024 at 07:59:35 AM +01:00:00, Markus Volk <f_l_k@t-online.de> wrot= e:
On Thu,= Oct 31 2024 at 11:45:59 PM +01:00:00, Martin Jansa <martin.jansa@gmail.= com> wrote:
Not sure if this was worth it :).

An easy way to hack this might also be somethi= ng like this ?

# Did this just for testing purpose=
export nonarch_libdir =3D "/usr/lib32"

= do_install:append() {
 if [ ! "${libdir}" =3D "${nonarch_lib= dir}" ]; then mkdir ${D}${nonarch_libdir};mv ${D}${libdir}/snapper ${D}${no= narch_libdir}/snapper; fi
}


FILES:${PN} +=3D "${nonarch_libdir}/snapper ${libdir}/pam_snapper ${syst= emd_system_unitdir} ${libdir}/security ${datadir}"

Since I'm not building multilib, I just did an export for nonarch_lib= dir to have a difference here for testing. Kind of seemed to work.
The 'mkdir' command is probably  only needed in my testcase, because= if building multilib the ${D}${nonarch_libdir} directory is presumably alr= eady present

Not pretty but eventually less = maintainance than a patch
--=-N2j8SgYeLRs0ZvmFWPra--