Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Graham Gower <graham.gower@gmail.com>
Subject: Re: opkg: Update svn 625 -> 633 and fix preinst issues
Date: Sat, 17 Dec 2011 01:32:28 +0000	[thread overview]
Message-ID: <1324085548.4568.121.camel@ted> (raw)
In-Reply-To: <20111217011658.GE3997@jama.jama.net>

On Sat, 2011-12-17 at 02:16 +0100, Martin Jansa wrote:
> On Thu, Dec 15, 2011 at 09:08:49PM +0000, Richard Purdie wrote:
> > There is a major issue with opkg images at the moment as preinst
> > functions are not being executed before their dependencies are installed
> > and this is leading to corruption of images containing avahi/dbus in
> > particular.
> > 
> > There are various changes in upstream opkg in the last 8 revisions which
> > make changes in this area but sadly these aren't enough to get things
> > working for us. I've updated to the latest svn revision with this patch
> > since it makes sense to pull in those changes first and then supplement
> > them with the attached patches.
> > 
> > There is a full description of the patches in the patch headers but in
> > summary they:
> > 
> > a) Ensure preinst functions execute with their dependencies installed.
> >    This is a pretty invasive change as it changes the package install
> >    ordering in general.
> > b) Ensure opkg sets $D, not $PKG_ROOT which we don't use
> > c) Change opkg to allow execution of postinstall functions which fail
> >    resulting in execution on the target device as rootfs_ipk.bbclass
> >    currently does manually.
> > 
> > The remaining changes interface this with the rest of the OE build
> > infrastructure, adding in the option to tell opkg to run the preinst and
> > postinst functions, ensure the correct environment is present for the
> > postinst scripts and removing the now unneeded rootfs_ipk class code
> > which opkg now does itself.
> > 
> > [YOCTO #1711]
> 
> Hi,
> 
> today I got image build failing with this and it seems like some kind of
> circular dependency or something.
> 
> In fsogsmd_git.bb we have:
> PACKAGES =+ "${PN}-connman ${PN}-connman-dev ${PN}-connman-dbg"
> RDEPENDS_${PN} += "${PN}-connman"
> 
> and there is also fsogsmd-connman dependency on fsogsmd (because of shlibs),
> so it's really circular dependency between runtime packages and new opkg cannot
> deal with it.
> 
> Then in log.do_rootfs
> Installing fsogsmd (1:0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7) to root...
> Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/qemuarm/fsogsmd_0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7_qemuarm.ipk.
> Installing fsogsmd-connman (1:0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7) to root...
> Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/qemuarm/fsogsmd-connman_0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7_qemuarm.ipk.
> Installing fsogsmd (1:0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7) to root...
> Installing fsogsmd-connman (1:0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7) to root...
> and then this last 2 lines 1794/2 times
> Installing fsogsmd (1:0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7) to root...
> Installing fsogsmd-connman (1:0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7) to root...
> Installing task-core-ssh-openssh (1.0-r0) to root...
> Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv5te/task-core-ssh-openssh_1.0-r0_armv5te.ipk.
> ...
> and in the end:
> ERROR: Function 'do_rootfs' failed (see /OE/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/shr-lite-image/2.0-r20/temp/log.do_rootfs.20387 for further information)
> Collected errors:
>  * gz_close: Unzip process killed by signal 11.
> 
>  * pkg_get_installed_files: Error extracting file list from /tmp/opkg-T7G08e/fsogsmd-connman_0.5.0+gitr20+96698077b6ccd5fc1222e0b2b9fc56d087c6c528-r6.7_qemuarm.ipk.
>  * opkg_install_cmd: Cannot install package task-shr-minimal-apps.
> 
> Reverting this patch and rebuilding opkg before running image build helps.
> 
> I'll try to upgrade only opkg without your patches first, but I guess it's
> because of fix_installorder.patch, can we teach it to break circular dependencies
> or should I fix it in metadata? It seem that longer cycles like
> 
> fsogsmd-config -> fsogsmd-module-modem-ti-calypso -> fsogsmd -> fsogsmd-config
> 
> does work.

This is likely as a result of the installorder patch :/. Sadly if we
want the postinstalls to be installed in order we do need that patch.

The question is whether circular depends are something opkg should
support or not? What's debian's behaviour in that regard?

Cheers,

Richard





  reply	other threads:[~2011-12-17  1:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 21:08 opkg: Update svn 625 -> 633 and fix preinst issues Richard Purdie
2011-12-17  1:16 ` Martin Jansa
2011-12-17  1:32   ` Richard Purdie [this message]
2011-12-17  9:20     ` Martin Jansa
2011-12-17 10:22       ` Richard Purdie
2011-12-17 10:34         ` Martin Jansa
2011-12-17 11:52           ` Richard Purdie
2011-12-17 15:47             ` Martin Jansa
2011-12-18 11:00             ` Martin Jansa
2011-12-18 11:44               ` Andreas Müller
2011-12-18 12:09                 ` Martin Jansa
2011-12-18 23:59                 ` Richard Purdie
2011-12-19  5:54                   ` Martin Jansa
2011-12-19  8:04                     ` [PATCH] opkg: add patch to make sure that D is empty when executing postinst scripts on target Martin Jansa
2011-12-18 10:37     ` opkg: Update svn 625 -> 633 and fix preinst issues Enrico Scholz

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=1324085548.4568.121.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=graham.gower@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox