Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: Peter Bergin <peter@berginkonsult.se>,
	openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] systemd: change syntax for SRC_URI append
Date: Tue, 1 Nov 2022 11:39:58 +0200	[thread overview]
Message-ID: <Y2DpbhnSdM2tyyyw@nuoska> (raw)
In-Reply-To: <CANNYZj-8-Ao5yj=rU7qS9oK=mBASs0Fm0=28sxp849DCOSVw-g@mail.gmail.com>

Hi,

On Tue, Nov 01, 2022 at 10:10:45AM +0100, Alexander Kanavin wrote:
> On Tue, 1 Nov 2022 at 09:12, Peter Bergin <peter@berginkonsult.se> wrote:
> > This opened my eyes for the way systemd recipes are built up in oe-core.
> > It seems a bit the other way around. systemd.inc contains almost only
> > version information. systemd_251.4.bb is huge and contains a lot of
> > thing that I think can be shared among versions. If it had been the
> > other way around it had been easy to have a systemd_git.bb, including
> > systemd.inc, in my local layer (or upstream if desired) that build
> > systemd main branch. What do you think of that? Is is worth working on
> > such a patch? Or are there reasons for that setup?
> 
> I prefer the opposite actually. Where possible, I fold the .inc files
> into the main recipe because that makes maintenance easier, and if
> someone needs to change that in non-upstreamable manner, they have to
> perform a full fork in a private layer. I do not like bits and pieces
> of code scattered all over the place and gathered together by bitbake,
> that does not help readability.

systemd contains both compiled code and large amounts of config files
which frequently need to be changed in various ways in real products. Think of
all the defaults for systemd-networkd, systemd-journald, service files etc.

Thus, it is common to have a bbappend for it which either patches
or otherwise changes these config files (e.g. sed in a
do_install_append()).

In these cases full fork of the poky side recipe is not needed or even
wanted.

What breaks these use cases is use of :append to change various
variables which users also need to change. A SRC_URI:append with 10's of
patches needs SRC_URI:remove for all of them, possibly increasing with
every security update gets really annoying in a .bbappend and users will
need to fully fork the recipes.

The .bb or .inc way of handling the main recipe doesn't really matter as
long it easy in a .bbappend to amend things to the variables like
SRC_URI and that these amendments work when there are small updates to
the recipe from e.g. LTS branch.

Cheers,

-Mikko


      parent reply	other threads:[~2022-11-01  9:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 21:09 [PATCH] systemd: change syntax for SRC_URI append Peter Bergin
2022-10-31 21:24 ` [OE-core] " Alexander Kanavin
2022-10-31 21:32   ` Peter Bergin
2022-10-31 21:54     ` Alexander Kanavin
2022-11-01  8:12       ` Peter Bergin
2022-11-01  9:10         ` Alexander Kanavin
2022-11-01  9:34           ` Martin Jansa
2022-11-01  9:39           ` Mikko Rapeli [this message]

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=Y2DpbhnSdM2tyyyw@nuoska \
    --to=mikko.rapeli@linaro.org \
    --cc=alex.kanavin@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter@berginkonsult.se \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox