All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: joerg.sommer@navimatix.de, "Marko, Peter" <Peter.Marko@siemens.com>
Cc: "openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>,
	 "mathieu.dubois-briand@bootlin.com"
	<mathieu.dubois-briand@bootlin.com>, "rs@ti.com" <rs@ti.com>
Subject: Re: [OE-core] [PATCH v3] bitbake.conf: Extend distro feature usrmerge to merge bin+sbin
Date: Mon, 24 Aug 2026 18:10:00 +0100	[thread overview]
Message-ID: <e9f73756611edc1054571655ff5ee041e71bb515.camel@linuxfoundation.org> (raw)
In-Reply-To: <aoxfc-dRzSygEkAb@navimatix.de>

On Mon, 2026-08-24 at 17:17 +0200, Jörg Sommer via lists.openembedded.org wrote:
> Marko, Peter schrieb am Mo 24. Aug, 13:11 (+0000):
> > [You don't often get email from peter.marko@siemens.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > systemd recipe has:
> > REQUIRED_DISTRO_FEATURES += "usrmerge"
> > So the changes in systemd recipe can be made unconditional.
> 
> I can update the commit, but with the current version, if someone doesn't
> like the bin-merge he can revert it and stay with usr-merge only.
> 
> But does really someone want this? Maybe somewhen systemd will require the
> bin-merge, too.
> 
> Any votes for or against hard-coding bin-merge?

I have wondered about changing the sdk layout (i.e. nativesdk) to merge
all the bin directories. That should really be independent of any of
the target layout/sysroot options.

I'm not sure where the patch would stand with regard to that...

Cheers,

Richard


  parent reply	other threads:[~2026-08-24 17:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24  9:00 [PATCH v2] bitbake.conf: Extend distro feature usrmerge to merge bin+sbin Jörg Sommer
2026-07-25  7:34 ` [OE-core] " Mathieu Dubois-Briand
2026-08-22  7:56 ` Jörg Sommer
2026-08-22 12:16   ` Mathieu Dubois-Briand
2026-08-22 14:09     ` Jörg Sommer
2026-08-24  6:30       ` Mathieu Dubois-Briand
2026-08-24  9:53         ` Jörg Sommer
2026-08-24 10:02           ` Mathieu Dubois-Briand
2026-08-24 12:43             ` Jörg Sommer
2026-08-24 13:10               ` Mathieu Dubois-Briand
2026-08-24 12:48 ` [PATCH v3] " Jörg Sommer
2026-08-24 13:11   ` [OE-core] " Marko, Peter
2026-08-24 15:17     ` joerg.sommer
2026-08-24 16:18       ` Marko, Peter
2026-08-24 17:10       ` Richard Purdie [this message]
2026-08-25  7:33   ` Mathieu Dubois-Briand

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=e9f73756611edc1054571655ff5ee041e71bb515.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Peter.Marko@siemens.com \
    --cc=joerg.sommer@navimatix.de \
    --cc=mathieu.dubois-briand@bootlin.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=rs@ti.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.