[OE-core] [PATCH] Better support for upgrading packages in opkg and update-rc.d.bbclass

Andreas Oberritter obi at opendreambox.org
Sat Oct 11 16:04:20 UTC 2014


On 10.10.2014 18:45, Peter Urbanec wrote:
> init-ifupdown inherits default implementations of prerm, postrm, preinst
> and postinst from update-rc.d.bbclass. Unfortunately these default
> implementations don't deal with package upgrades as well as they could.
> 
> What ends up happening is that opkg starts downloading and unpacking
> packages sequentially. As it downloads and unpacks each package, opkg
> calls prerm, preinst and postrm hook scripts. Once all packages are
> unpacked, the postinst script is finally called for all packages as part
> of the "configure" stage.
> 
> In the case of init-ifupdown, the default prerm and preinst scripts stop
> networking.

I think prerm and postrm scripts should exit silently on upgrade. At
least that's what happens with rpm and with a patch just submitted for
deb [1]. I guess ipk should implement the same logic, for which your
patch to opkg is a prerequisite.

> Networking is not brought back up again until the init-ifupdown
> postinst is called, but that only happens after all the packages have been
> downloaded, unpacked and installed. This leaves a window where any package
> that needs to be downloaded after init-ifupdown is encountered will fail.
> 
> This patch fixes the problem by enhancing opkg to also provide the "upgrade"
> argument to prerm and postrm, to (partially) match what dpkg does. See
> https://wiki.debian.org/MaintainerScripts for dpkg diagrams that clarify
> the intended process. opkg lacks the full functionality of dpkg, but for
> the purpose of this exercise, they are similar enough.
> 
> I have submitted a patch to the opkg-devel list to include the "upgrade"
> argument in future version of opkg.
> 
> The second part of the solution is an update to the default implementations
> of the pre- and post- scripts provided by update-rc.d.bbclass. The scripts
> are now careful to remove the package init scripts using the old package
> context and to delay the restart of a service until the configure stage,
> called from the postinst script.
> 
> ---
>  meta/classes/update-rc.d.bbclass                   | 75 +++++++++++++---------
>  .../opkg/upgrade-argument-for-pre_postrm.patch     | 30 +++++++++
>  meta/recipes-devtools/opkg/opkg_0.2.2.bb           |  1 +
>  3 files changed, 77 insertions(+), 29 deletions(-)
>  create mode 100644 meta/recipes-devtools/opkg/opkg/upgrade-argument-for-pre_postrm.patch
> 
> diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
> index bc1aa7d..c29457f 100644
> --- a/meta/classes/update-rc.d.bbclass
> +++ b/meta/classes/update-rc.d.bbclass
> @@ -14,45 +14,62 @@ INITSCRIPT_PARAMS ?= "defaults"
>   INIT_D_DIR = "${sysconfdir}/init.d"
>  -updatercd_preinst() {
> -if [ -z "$D" -a -f "${INIT_D_DIR}/${INITSCRIPT_NAME}" ]; then
> -	${INIT_D_DIR}/${INITSCRIPT_NAME} stop
> +# During an upgrade, the pre/postrm scripts from old package are called
> +# and the pre/postinst scripts called are from the new package.
> +# See https://wiki.debian.org/MaintainerScripts for dpkg diagrams.
> +# opkg uses a subset, which lacks most of the error handling.
> +
> +# Old package context, step 1
> +updatercd_prerm() {
> +if [ "x$1" != "xupgrade" ] ; then

I think using "x..." syntax is obsolete. "$1" != "upgrade" should work
with every supported shell and is easier to read.

This part of the patch wouldn't be needed if package_ipk.bbclass
implemented the same logic as rpm mentioned above.

But, on the other hand, maybe package_rpm.bbclass is wrong... ;-)

> +  ${INIT_D_DIR}/${INITSCRIPT_NAME} stop
>  fi
> -if type update-rc.d >/dev/null 2>/dev/null; then
> -	if [ -n "$D" ]; then
> -		OPT="-f -r $D"
> -	else
> -		OPT="-f"
> -	fi
> -	update-rc.d $OPT ${INITSCRIPT_NAME} remove
> +if [ -z "$D" ]; then
> +  OPT=""
> +else
> +  OPT="-r $D"
>  fi
> -}
> -
> -updatercd_postinst() {
>  if type update-rc.d >/dev/null 2>/dev/null; then
> -	if [ -n "$D" ]; then
> -		OPT="-r $D"
> -	else
> -		OPT="-s"
> -	fi
> -	update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
> +  update-rc.d $OPT ${INITSCRIPT_NAME} remove
>  fi
>  }
>  -updatercd_prerm() {
> -if [ -z "$D" ]; then
> -	${INIT_D_DIR}/${INITSCRIPT_NAME} stop
> -fi
> +# New package context, step 2
> +updatercd_preinst() {
> +case "$1" in
> +  upgrade)
> +    ;;
> +  *)
> +    ;;
> +esac
>  }
>  +# Old package context, step 3
>  updatercd_postrm() {
> +case "$1" in
> +  upgrade)
> +    ;;
> +  *)
> +    ;;
> +esac
> +}
> +

The two functions above don't do anything, so they should be removed.

> +# N.B. Step 4 runs after all packages have been through steps 1-3 and therefore we
> +#      need to delay service restarts during upgrade until here. Otherwise we end
> +#      up with situations, like networking going down in the middle of "opkg upgrade",
> +#      thus resulting in failures to fetch further packages.
> +
> +# New package context, step 4
> +updatercd_postinst() {
>  if type update-rc.d >/dev/null 2>/dev/null; then
> -	if [ -n "$D" ]; then
> -		OPT="-r $D"
> -	else
> -		OPT=""
> -	fi
> -	update-rc.d $OPT ${INITSCRIPT_NAME} remove
> +  if [ -n "$D" ]; then
> +    OPT="-r $D"
> +  else
> +    # This will catch the upgrade case and result in a restart.
> +    ${INIT_D_DIR}/${INITSCRIPT_NAME} stop
> +    OPT="-s"
> +  fi
> +  update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}

I have patches to update-rc.d [2] and update-rc.d.bbclass [3] to improve
handling of distributions with both systemd and sysvinit distro features
enabled. What they try to avoid is direct calls to init scripts, where
systemd may provide own unit files. Would it be feasible to use
update-rc.d to issue a restart command?

Regards,
Andreas

[1]:
http://lists.openembedded.org/pipermail/openembedded-core/2014-October/097872.html
[2]:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=obi/master&id=a4e4f2083f693f1715e589eda6dd403f311086fe
[3]:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=obi/master&id=68080e144cb894b41bca5a1ca74d1e18fb00104c



More information about the Openembedded-core mailing list