From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Phil Blundell <pb@pbcl.net>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] rootfs_ipk: respect ONLINE_PACKAGE_MANAGEMENT
Date: Thu, 19 May 2011 13:16:36 +0100 [thread overview]
Message-ID: <1305807396.3424.510.camel@rex> (raw)
In-Reply-To: <1305805268.18415.185.camel@lenovo.internal.reciva.com>
On Thu, 2011-05-19 at 12:41 +0100, Phil Blundell wrote:
> On Thu, 2011-05-19 at 12:21 +0100, Richard Purdie wrote:
> > On Thu, 2011-05-19 at 11:31 +0100, Phil Blundell wrote:
> > Agreed. I'd like to raise one other issue which is the number of
> > variables we need to control these things which are effectively binary
> > flags. I'm leaning towards having a small number of variables containing
> > flags which trigger certain behaviours. In this case the obvious choices
> > would be:
>
> That's true, though one particular variable at hand is actually a
> trinary. The behaviour that we have historically had in OE, which seems
> to capture most of the significant use-cases, is:
>
> ONLINE_PACKAGE_MANAGEMENT="full" (or not set at all) means to install
> opkg or whatever and all its metadata, like oe-core does now
>
> ONLINE_PACKAGE_MANAGEMENT="none" means to not install opkg or its
> metadata on the target at all;
>
> ONLINE_PACKAGE_MANAGEMENT="add" means to install just enough package
> management infrastructure to allow new packages to be added after the
> fact, but not to allow packages that were shipped in the image to be
> manipulated. I think the main use case for this was language packs and
> the like.
>
> I'm not entirely sure that O_P_M="add" has ever actually worked properly
> (I don't use it myself) but it doesn't seem like an entirely worthless
> proposition.
This could be done as:
IMAGE_FEATURES = "packageaddonly"
with errors if two mutually exclusive flags were specified
("nopackagemanager packageaddonly").
Also, for reference in core-image.bbclass there is already this code:
${@base_contains("IMAGE_FEATURES", "package-management", "${ROOTFS_PKGMANAGE}", "${ROOTFS_PKGMANAGE_BOOTSTRAP}",d)} \
which means OE-Core adds the package manager if requested
(ROOTFS_PKGMANAGE) and otherwise installs ROOTFS_PKGMANAGE_BOOTSTRAP
which corresponds to enough scripting to handle the postinstalls.
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.
Cheers,
Richard
next prev parent reply other threads:[~2011-05-19 12:19 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 [this message]
2011-05-19 15:04 ` Phil Blundell
2011-05-19 15:08 ` Richard Purdie
2011-05-24 13:59 ` Phil Blundell
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=1305807396.3424.510.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=pb@pbcl.net \
/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