public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Andreas Müller" <schnitzeltony@googlemail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] systemd.bbclass: Introduce do_install_append and use systemd unitdir
Date: Wed, 13 Feb 2013 00:14:08 +0000	[thread overview]
Message-ID: <1360714448.11225.16.camel@ted> (raw)
In-Reply-To: <CALbNGRSiit5QwsYsrAbWhGQUzgCYYjScUdZPuoBxCDRDgOKbgQ@mail.gmail.com>

On Wed, 2013-02-13 at 00:55 +0100, Andreas Müller wrote:
> On Tue, Feb 12, 2013 at 10:24 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Tue, 2013-02-12 at 09:42 -0800, Khem Raj wrote:
> >> systemd always uses /lib and /usr/lib to store unit files
> >> so using libdir and base_libdir is incorrect. It will work
> >> where libdir is usr/lib and base_libdir is /lib but wont work
> >> when say its /lib64
> >>
> >> Additionally introduce the install append from meta-oe
> >> lot of recipe appends in meta-systemd depend on that
> >>
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >> ---
> >>  meta/classes/systemd.bbclass |   21 +++++++++++++++------
> >>  1 file changed, 15 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
> >> index e0ea65c..32cc5c2 100644
> >> --- a/meta/classes/systemd.bbclass
> >> +++ b/meta/classes/systemd.bbclass
> >> @@ -115,11 +115,9 @@ def systemd_populate_packages(d):
> >>
> >>      # Check service-files and call systemd_add_files_and_parse for each entry
> >>      def systemd_check_services():
> >> -        base_libdir = d.getVar('base_libdir', True)
> >> -        searchpaths = [oe.path.join(d.getVar("sysconfdir", True), "systemd", "system"),]
> >> -        searchpaths.append(oe.path.join(d.getVar("base_libdir", True), "systemd", "system"))
> >> -        searchpaths.append(oe.path.join(d.getVar("libdir", True), "systemd", "system"))
> >> -        searchpaths.append(oe.path.join(d.getVar("libdir", True), "systemd", "user"))
> >> +        searchpaths = '/etc/systemd/system/' + ' '
> >
> > Why remove sysconfdir?
> >
> > Also, lets standardise on one variable please. We have
> > ${nonarch_base_libdir} and ${systemd_unitdir} so do we need to
> > hardcode /lib and /usr/lib?
> >
> > I'd suggest we add ${nonarch_libdir}, standardise on those and drop
> > systemd_unitdir. We use the nonarch for other non-systemd multilib work.
> >
> >> +        searchpaths += '/lib/systemd/system/' + ' '
> >> +        searchpaths += '/usr/lib/systemd/system/' + ' '
> >>          systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
> >>          has_exactly_one_service = len(systemd_packages.split()) == 1
> >>          if has_exactly_one_service:
> >> @@ -133,7 +131,7 @@ def systemd_populate_packages(d):
> >>          for pkg_systemd in systemd_packages.split():
> >>              for service in get_package_var(d, 'SYSTEMD_SERVICE', pkg_systemd).split():
> >>                  path_found = ''
> >> -                for path in searchpaths:
> >> +                for path in searchpaths.split():
> >>                      if os.path.exists(oe.path.join(d.getVar("D", True), path, service)):
> >>                          path_found = path
> >>                          break
> >> @@ -156,3 +154,14 @@ python populate_packages_prepend () {
> >>      if oe.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
> >>          systemd_populate_packages (d)
> >>  }
> >> +# automatically install all *.service and *.socket supplied in recipe's SRC_URI
> >> +do_install_append() {
> >> +     for service in `find ${WORKDIR} -maxdepth 1 -name '*.service' -o -name '*.socket'` ; do
> >> +     # ensure installing systemd-files only (e.g not avahi *.service)
> >> +             if grep -q '\[Unit\]' $service ; then
> >> +                     install -d ${D}${systemd_unitdir}/system
> >> +                     install -m 644 $service ${D}${systemd_unitdir}/system
> >> +             fi
> >> +     done
> >> +}
> >> +
> >
> > Please no. We have this kind of mess from the binconfig class and its
> > horrible to maintain. I'm looking forward to ripping that class out
> > someday.
> >
> > Lets just write proper do_install functions in the recipes and make them
> > conditional on systemd being enabled.
> >
> Copying similar code in in tons of recipes is easier to maintain?

Its dangerous and risky. This code sits silently in the class file and
copies files. Imagine some project starts installing its own service
files yet someone doesn't notice when they upgrade the recipe. All of a
sudden we start overwriting files and nobody notices. This does happen
as things get adopted by upstreams.

This is the big problem with the binconfig class, it overwrites anything
do_install does. We have so much history there we don't dare touch it
either. How did we get there? Originally packages didn't provide -config
files. Personally, I can't wait to delete the thing.

> We had this before meta-systemd started and it was a mess. How about a
> variable SYSTEMD_AUTO_INSTALL?="enable" for this - since it fits in
> many cases.

At least spell out which files to install:

SYSTEMD_EXTRAINSTALL = "${WORKDIR}/xxxx.service"

then the user stands a better change of spotting a conflict. Yes, I know
the files are listed in SRC_URI but I don't think its enough. We can
also throw an error if the files already exist.

There is a time and a place for magic things behind the scenes but IME
find calls in functions like this don't end well. The "ignore avahi
service files" issue in the code already should serve as a suitable
warning too.

Cheers,

Richard





  reply	other threads:[~2013-02-13  0:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 17:42 [PATCH] systemd.bbclass: Introduce do_install_append and use systemd unitdir Khem Raj
2013-02-12 21:05 ` Burton, Ross
2013-02-12 21:24 ` Richard Purdie
2013-02-12 23:55   ` Andreas Müller
2013-02-13  0:14     ` Richard Purdie [this message]
2013-02-13 17:52     ` Phil Blundell
2013-02-14  2:23       ` Khem Raj

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=1360714448.11225.16.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=schnitzeltony@googlemail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox