All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: should recipes not come with their own systemd/user/group info?
Date: Thu, 5 Aug 2021 07:01:09 -0400 (EDT)	[thread overview]
Message-ID: <d9126d7b-13ed-6a37-1db8-2affecbca83@crashcourse.ca> (raw)


  style question here, but i'm perusing an OE/YP (actually wind river,
but effectively the same thing) layer that was handed to me, and i'm
puzzled by how the internally-written systemd-controlled services are
implemented.

  on the one hand, there are reasonable recipes that each represent
some service to be managed by systemd, and they all install their
executables in the right places and so on. however, rather than each
recipe also providing its own service file, there is a totally
separate recipe (call it "systemd-services.bb") which contains under
its files/ directory dozens and dozens of service files for all of
those recipes, and is responsible for installing all of them.

  in short, someone decided that -- for whatever reason -- all of the
systemd service files should be collected all in one place, and
installed en masse. is this ... normal? i would have thought that it's
the responsibility of each recipe to mannage all the content related
to it, and that would of course include the systemd service file to be
installed for it. i don't know the rationale for this, and it strikes
me as a recipe for disaster in trying to keep all these things synced
up. is there some rationale for doing it this way that i'm unaware
of?

  and closely related, the same trick was used when defining all the
new users and groups that would own these services. rather than each
service looking after itself, there is a recipe file (call it
"new_users_and_groups.bb") which is hundreds of lines of USERADD_PARAM
and GROUPADD_PARAM lines that define precisely (numerically) all the
new user and group accounts to be associated with all sorts of
services, whereupon i ask the same question -- isn't it more typical
that each service look after its own user and group info?

  in this second case, it *might* be that all of these values need to
be hard-coded to be consistent with, i don't know, something else i'm
unaware of, but it still looks strange.

  thoughts? the above actually works for the time being, but it does
seem a but unnatural.

rday

             reply	other threads:[~2021-08-05 11:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 11:01 Robert P. J. Day [this message]
2021-08-05 15:35 ` [OE-core] should recipes not come with their own systemd/user/group info? Khem Raj
2021-08-05 18:49 ` Mark Hatle

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=d9126d7b-13ed-6a37-1db8-2affecbca83@crashcourse.ca \
    --to=rpjday@crashcourse.ca \
    --cc=openembedded-core@lists.openembedded.org \
    /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.