From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Esben Haabendal <eha@dev.doredevelopment.dk>
Cc: poky <poky@yoctoproject.org>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [poky] Proposed Multilib Implementation Brainstorming
Date: Wed, 06 Apr 2011 05:05:54 -0700 [thread overview]
Message-ID: <1302091554.22904.18.camel@rex> (raw)
In-Reply-To: <87y63n5028.fsf@eha.doredevelopment.dk>
On Wed, 2011-04-06 at 09:08 +0200, Esben Haabendal wrote:
> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
>
> > One of the items on our post 1.0 schedule is multilib and we need a plan
> > of implementation. I've been thinking about this for a while and at
> > least have some ideas how some of the issues can be handled.
> > ....
> > Does this make sense to everyone, are there any questions/ objections/
> > concerns/ things I've missed?
>
> Which actual OE use-cases justify this kind of addition to OE?
Several people wanting to use OECore have a requirement of multilib
support. The typical embedded use case is where you have one main
application which you might want to run in some kind of large memory
mode or with some special optimisation (think a database engine) whilst
the rest of the system is "standard". This requires the ability to mix
different libraries.
> I know it is on the Yocto post 1.0 schedule, but is it actually a good
> thing for OE? Maintaining OE recipes is clearly not going to get any
> easier with multilibs support.
As detailed in the proposal you will see that the complexity added is
minimal. It requires a simple enhancement to BBCLASSEXTEND which is
likely desirable for other reasons too and that is the only real bitbake
change required. For the metadata, individual recipes remain unaffected
and also the core conf files are unchanged too. The toolchain dependency
changes will be the only change affecting users at the recipe level and
most of the class/machine configuration will be opt in by anyone using
multilib. The only other invasive change is the package manager
integration. For rpm, it has good support for multilib already and we're
just enabling that. For opkg, we still need to determine the best
approach but the simplistic approach I mentioned will probably suffice
and anyone wanting true support at the package manager level can use
rpm.
For day to day recipe maintenance I don't see much direct impact.
Cheers,
Richard
next prev parent reply other threads:[~2011-04-06 12:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-05 11:02 Proposed Multilib Implementation Brainstorming Richard Purdie
2011-04-05 23:28 ` Jeremy Puhlman
2011-04-06 18:53 ` Richard Purdie
2011-04-06 7:08 ` Esben Haabendal
2011-04-06 12:05 ` Richard Purdie [this message]
2011-04-06 12:16 ` [poky] " Esben Haabendal
2011-04-06 13:06 ` Richard Purdie
2011-04-06 13:21 ` Esben Haabendal
2011-04-06 14:19 ` Richard Purdie
2011-04-06 16:38 ` Esben Haabendal
2011-04-06 18:01 ` Hatle, Mark
2011-04-06 20:54 ` Esben Haabendal
2011-04-06 20:55 ` Esben Haabendal
2011-04-06 7:16 ` Koen Kooi
2011-04-06 8:47 ` Frans Meulenbroeks
2011-04-06 14:29 ` Richard Purdie
2011-04-06 18:06 ` [poky] " Hatle, Mark
2011-04-06 18:25 ` Tom Rini
2011-04-07 6:10 ` Koen Kooi
2011-04-06 18:26 ` Hatle, Mark
2011-04-06 18:39 ` Tom Rini
2011-04-07 15:36 ` [poky] " Colin Walters
2011-04-07 16:10 ` Hatle, Mark
2011-04-07 16:53 ` Colin Walters
2011-04-07 17:04 ` Hatle, Mark
2011-04-07 17:10 ` Hatle, Mark
2011-04-07 17:07 ` Koen Kooi
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=1302091554.22904.18.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=eha@dev.doredevelopment.dk \
--cc=openembedded-core@lists.openembedded.org \
--cc=poky@yoctoproject.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