Openembedded Core Discussions
 help / color / mirror / Atom feed
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.





  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