From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from cpanel7.indieserve.net (cpanel7.indieserve.net [199.212.143.8]) by mx.groups.io with SMTP id smtpd.web10.6615.1585998211600277784 for ; Sat, 04 Apr 2020 04:03:32 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: crashcourse.ca, ip: 199.212.143.8, mailfrom: rpjday@crashcourse.ca) Received: from cpeac202e043973-cmac202e043970.sdns.net.rogers.com ([174.114.100.179]:51540 helo=localhost.localdomain) by cpanel7.indieserve.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jKgaH-002Okk-Rh; Sat, 04 Apr 2020 07:03:30 -0400 Date: Sat, 4 Apr 2020 07:03:27 -0400 (EDT) From: "rpjday@crashcourse.ca" X-X-Sender: rpjday@localhost.localdomain To: Richard Purdie cc: OE Core mailing list Subject: Re: [OE-core] trivial(?) question about post-installation scripts In-Reply-To: <5d2d70a05eeb516678cf3b11abd7b948d197e341.camel@linuxfoundation.org> Message-ID: References: <5d2d70a05eeb516678cf3b11abd7b948d197e341.camel@linuxfoundation.org> MIME-Version: 1.0 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel7.indieserve.net X-AntiAbuse: Original Domain - lists.openembedded.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - crashcourse.ca X-Get-Message-Sender-Via: cpanel7.indieserve.net: authenticated_id: rpjday+crashcourse.ca/only user confirmed/virtual account not confirmed X-Authenticated-Sender: cpanel7.indieserve.net: rpjday@crashcourse.ca X-Source: X-Source-Args: X-Source-Dir: Content-Type: text/plain; charset=US-ASCII 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