From: Tom Rini <tom.rini@gmail.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Consistency and use cases for IMAGE_FSTYPES
Date: Fri, 23 Mar 2012 08:48:26 -0700 [thread overview]
Message-ID: <20120323154826.GC9551@bill-the-cat> (raw)
In-Reply-To: <1332465264.9740.380.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]
On Fri, Mar 23, 2012 at 01:14:24AM +0000, Richard Purdie wrote:
> On Thu, 2012-03-22 at 19:53 -0400, Denys Dmytriyenko wrote:
> > On Thu, Mar 22, 2012 at 11:26:24PM +0000, Richard Purdie wrote:
> > > On Fri, 2012-03-09 at 14:39 -0700, Tom Rini wrote:
> > > > Hey all,
> > > >
> > > > Over in meta-ti I kicked off a discussion
> > > > (https://lists.yoctoproject.org/pipermail/meta-ti/2012-March/000779.html)
> > > > about if we should be using '?=' or '+=' with IMAGE_FSTYPES in the
> > > > machine conf files. This has been discussed a little bit before
> > > > (http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/2060/focus=2061).
> > > > The problem is we have the following and I believe ultimately
> > > > conflicting use cases:
> > >
> > > I've been under the impression that we decided upon:
> > >
> > > > - The machine needs to say 'I need or support the following formats'
> > >
> > > so the machine starts and sets:
> > >
> > > IMAGE_FSTYPES = "xxxx"
> > >
> > > > - The distro needs to say 'I always want format X'
> > >
> > > so the distro can do:
> > >
> > > IMAGE_FSTYPES += " yyy"
> > >
> > > > - The user needs to say 'I know best, give me only format X'
> > >
> > > So the user can do:
> > >
> > > IMAGE_FSTYPES = "X"
> >
> > Since local.conf gets parsed before machine.conf and distro.conf, the user
> > needs to do this override:
> >
> > IMAGE_FSTYPES_local = "X"
> >
> > Otherwise machine.conf will always overwrite it with "xxxx" with its
> > unconditional assignment.
>
> Right, I'd forgotten that little detail :/.
>
> It actually makes me wonder if our include order is the right one but
> now isn't the time to try changing that.
>
> I agree the neatest way to change it is probably something like
> MACHINE_FSTYPES. I do worry a lot about backwards compatibility though
> and I'd also point out where we're at in the release cycle (bug fix
> only).
Well, one problem that would make this a bugfix is that no one does what
you say we agreed on today. oe-core has qemu.inc using ?=, meta-intel
is using += and meta-ti is mixed (which is what got this started).
--
Tom
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2012-03-23 15:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-09 21:39 Consistency and use cases for IMAGE_FSTYPES Tom Rini
2012-03-10 6:29 ` Koen Kooi
2012-03-12 20:25 ` Denys Dmytriyenko
2012-03-22 21:40 ` Tom Rini
2012-03-22 23:26 ` Richard Purdie
2012-03-22 23:53 ` Denys Dmytriyenko
2012-03-23 1:14 ` Richard Purdie
2012-03-23 15:48 ` Tom Rini [this message]
2012-03-23 16:17 ` Darren Hart
2012-03-23 16:29 ` Tom Rini
2012-03-23 16:34 ` Darren Hart
2012-03-23 17:03 ` Tom Rini
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=20120323154826.GC9551@bill-the-cat \
--to=tom.rini@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.