From: Phil Blundell <pb@pbcl.net>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] rootfs_ipk: respect ONLINE_PACKAGE_MANAGEMENT
Date: Tue, 24 May 2011 14:59:17 +0100 [thread overview]
Message-ID: <1306245557.2525.192.camel@phil-desktop> (raw)
In-Reply-To: <1305817704.3424.531.camel@rex>
On Thu, 2011-05-19 at 16:08 +0100, Richard Purdie wrote:
> On Thu, 2011-05-19 at 16:04 +0100, Phil Blundell wrote:
> > On Thu, 2011-05-19 at 13:16 +0100, Richard Purdie wrote:
> > > So if we:
> > >
> > > a) Only add ROOTFS_PKGMANAGE_BOOTSTRAP if postinstalls were present
> > > b) Add the read-only-rootfs option we discussed which errors if
> > > postinstalls are present
> > >
> > > we end up a lot closer to where you want to be.
> >
> > Yes, sounds reasonable. And I think we could then eliminate
> > remove_packaging_data_files() altogether, in favour of having the right
> > thing happen automatically during rootfs construction, which would
> > probably be a good thing too.
>
> Agreed, I think we have a plan :)
One other thing that occurred to me is that ONLINE_PACKAGE_MANAGEMENT
(in classic oe) is a DISTRO feature rather than an image one. This is
significant because, for example, update-rc.d.bbclass doesn't include
update-rc.d in RDEPENDS if it knows that the package will never be
installed on a running target. If we're going to make package
management into an IMAGE_FEATURE then obviously this isn't going to work
as it stands.
I guess we could work around it by letting update-rc.d add its
dependency as normal, and then adding code to the rootfs constructor to
stop it taking effect (and/or substitute a dummy update-rc.d package
with no files in) if an image with no package management is being
generated. That doesn't seem terribly elegant but, short of going back
to a DISTRO-based selection, I can't think of any better way of fixing
it.
p.
next prev parent reply other threads:[~2011-05-24 14:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-17 13:55 [PATCH] rootfs_ipk: respect ONLINE_PACKAGE_MANAGEMENT Phil Blundell
2011-05-17 14:24 ` Richard Purdie
2011-05-17 14:50 ` Phil Blundell
2011-05-17 16:22 ` Richard Purdie
2011-05-18 15:37 ` Phil Blundell
2011-05-19 10:15 ` Richard Purdie
2011-05-19 10:31 ` Phil Blundell
2011-05-19 11:21 ` Richard Purdie
2011-05-19 11:41 ` Phil Blundell
2011-05-19 12:16 ` Richard Purdie
2011-05-19 15:04 ` Phil Blundell
2011-05-19 15:08 ` Richard Purdie
2011-05-24 13:59 ` Phil Blundell [this message]
2011-05-24 14:12 ` Richard Purdie
2011-05-24 14:16 ` Phil Blundell
2011-05-19 16:58 ` Chris Larson
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=1306245557.2525.192.camel@phil-desktop \
--to=pb@pbcl.net \
--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