All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Volk <f_l_k@t-online.de>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: raj.khem@gmail.com, openembedded-devel@lists.openembedded.org
Subject: Re: [oe] [meta-oe][PATCH v3] snapper: add recipe
Date: Fri, 01 Nov 2024 13:03:49 +0100	[thread overview]
Message-ID: <DIT9MS.I2UFW3U29ROC@t-online.de> (raw)
In-Reply-To: <1803C5E0EFB35EE5.1077@lists.openembedded.org>

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

I have now set up a multilib build environment to see exactly how that 
works. If I haven't forgotten anything, it was easier than I thought. I 
added the following to local.conf:

require conf/multilib.conf
MULTILIBS = ā€œmultilib:lib32ā€
DEFAULTTUNE:virtclass-multilib-lib32 = ā€œx86ā€
IMAGE_INSTALL:append = ā€œ lib32-glibc lib32-libgcc lib32-libstdc++ 
snapper lib32-snapperā€

Then set FILES:${PN} like this:
FILES:${PN} += ā€œ${nonarch_libdir} ${systemd_system_unitdir} 
${datadir}ā€

And I was able to build core-image-minimal with both snapper and 
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 
<f_l_k@t-online.de> wrote:
> 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 something like this ?
> 
> # Did this just for testing purpose
> export nonarch_libdir = "/usr/lib32"
> 
> do_install:append() {
>  if [ ! "${libdir}" = "${nonarch_libdir}" ]; then mkdir 
> ${D}${nonarch_libdir};mv ${D}${libdir}/snapper 
> ${D}${nonarch_libdir}/snapper; fi
> }
> 
> 
> FILES:${PN} += "${nonarch_libdir}/snapper ${libdir}/pam_snapper 
> ${systemd_system_unitdir} ${libdir}/security ${datadir}"
> 
> Since I'm not building multilib, I just did an export for 
> nonarch_libdir 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 already present
> 
> Not pretty but eventually less maintainance than a patch


[-- Attachment #2: Type: text/html, Size: 2675 bytes --]

  parent reply	other threads:[~2024-11-01 12:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-20 15:08 [meta-oe][PATCH v3] snapper: add recipe Khem Raj
2024-10-24 10:47 ` [oe] " Martin Jansa
2024-10-31 17:25   ` Markus Volk
2024-10-31 17:45   ` Markus Volk
2024-10-31 18:15     ` Martin Jansa
     [not found]     ` <18039C488E2C1344.6352@lists.openembedded.org>
2024-10-31 22:45       ` Martin Jansa
2024-11-01  6:59         ` Markus Volk
     [not found]         ` <1803C5E0EFB35EE5.1077@lists.openembedded.org>
2024-11-01 12:03           ` Markus Volk [this message]
2024-11-03 10:36             ` Martin Jansa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DIT9MS.I2UFW3U29ROC@t-online.de \
    --to=f_l_k@t-online.de \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.