public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "rpjday@crashcourse.ca" <rpjday@crashcourse.ca>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] trivial(?) question about post-installation scripts
Date: Sat, 4 Apr 2020 07:03:27 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.21.2004040649120.9240@localhost.localdomain> (raw)
In-Reply-To: <5d2d70a05eeb516678cf3b11abd7b948d197e341.camel@linuxfoundation.org>

On Sat, 4 Apr 2020, Richard Purdie wrote:

> On Sat, 2020-04-04 at 05:52 -0400, rpjday@crashcourse.ca wrote:
> >   still working my way through the YP docs and, in dev manual,
> > 3.3.19,
> > "Post-Installation Scripts", one reads the final note:
> >
> > "Equivalent support for pre-install, pre-uninstall, and post-
> > uninstall
> > scripts exist by way of pkg_preinst, pkg_prerm, and pkg_postrm,
> > respectively. These scrips work in exactly the same way as does
> > pkg_postinst with the exception that they run at different times.
> > Also, because of when they run, they are not applicable to being run
> > at image creation time like pkg_postinst."
> >
> >   i'm confused ... why would a pkg_preinst script not be applicable
> > to
> > being run at image creation time? or am i misreading that?
> >
> >   i'll probably have more questions about these scripts as i dig
> > further into them.
>
> I think however wrote it misunderstood. prerm and postrm are unlikely
> to run at image install time (but can if packages are removed). preinst
> will run.

  just to clarify a couple more points about those scripts (and i'm
definitely going to rewrite the dev manual section on this after i
figure it out, with copious examples), as i read it, the pkg_postinst
script will normally be run at one of two times:

  * at image creation time if package is listed as part of the image, or
  * at a later time on a running system

the difference being that the first case requires the process to
recognize that the script is being run in the context of the image
directory $D.

  in some cases, it appears the script doesn't need to *explicitly*
check which context it's in, as using "$D" will automatically do the
right thing. here's an example from shutdown-desktop.bb:

  pkg_postinst_${PN} () {
    grep -q qemuarm $D${sysconfdir}/hostname && \
        sed -i $D${datadir}/applications/shutdown.desktop -e
              's#^Exec=\(.*\)/halt#Exec=\1/reboot#' \
        || true
  }

so (and correct me if i'm wrong), the use of "$D" above will simply do
the right thing as, in the first case, it will have the correct value
(that is, ${D}), and in the latter case, it will be empty and so will
simply work on a running system as well.

  in other cases, however, depending on the context, there might need
to be tweaks, as in this case from modutils-initscripts.bb:

  pkg_postinst_${PN} () {
    if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
        if [ -n "$D" ]; then
            OPTS="--root=$D"     <-- trivial tweak for image build time
        fi
        systemctl $OPTS mask modutils.service
    fi
  }

in short, all pkg_postinst_* scripts need to access $D, at least
implicitly, if they're designed to work in either context.

  as for an example of pkg_postinst_ontarget(), i've already found
opkg-keyrings_1.0.bb, which most readers will understand should be run
*only* at first boot time:

  pkg_postinst_ontarget_${PN} () {
  opkg-key populate
  }

slowly getting a handle on this ...

rday

      parent reply	other threads:[~2020-04-04 11:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-04  9:52 trivial(?) question about post-installation scripts rpjday
2020-04-04  9:58 ` [OE-core] " Richard Purdie
2020-04-04 10:14   ` rpjday
2020-04-04 11:03   ` rpjday [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=alpine.LFD.2.21.2004040649120.9240@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox