From: Tom Rini <tom_rini@mentor.com>
To: <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-oe][PATCH 0/2] Fix parse errors
Date: Tue, 28 Jun 2011 10:20:59 -0700 [thread overview]
Message-ID: <4E0A0D7B.3000602@mentor.com> (raw)
In-Reply-To: <BANLkTinrcfQvNW4=s5vbjD=8FhaqVYpbEQ@mail.gmail.com>
On 06/28/2011 10:14 AM, Frans Meulenbroeks wrote:
> 2011/6/28 Koen Kooi <koen@dominion.thruhere.net>
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 28-06-11 16:59, Otavio Salvador wrote:
>>> On Tue, Jun 28, 2011 at 11:51, Koen Kooi <koen@dominion.thruhere.net>
>> wrote:
>>>> I'm not going pull those in, since the whole point was to not make them
>>>> machine specific. RP has pushed a workaround for it so parsing
>>>> continues. I'll push a proper fix for systemd later.
>>>
>>> What's the difference if the package will be built from same source?
>>>
>>> In case you change anything you'll need to rebuild all packages anyway
>>> so I see no gain in having it per package.
>>
>> It makes it easier to deploy updates for the main packages (e.g.
>> sysvinit, systemd) to all the targets without having to build it for all
>> targets. It's a weird optimization, but makes life a lot easier for
>> people needing to support a ton of machines :)
>>
>
> Hm. saving some CPU cycles and wall clock time makes life a lot easier.
> Guess you haven't too much of a life then :-)
> No kidding, why not keep things simple. and elegant.
> (and actually people needing to maintain a lot of machines and keeping them
> up to date is somewhat an oddity anyway; My experience is that most embedded
> developers need to support only a few machines and typically freeze their
> sources and stabilize their product).
Really? One of those big requests we see a lot is for things like "how
can I support the N different revs of the board for this product".
Looking over at the kernel side of things that was one of the drivers
for device tree stuff. So yes, outside of community based distributions
like Angstrom and SHR and SlugOS and ... there are commercial uses for
this change as well. And it doesn't change the world of one machine
embedded products at all.
--
Tom Rini
Mentor Graphics Corporation
next prev parent reply other threads:[~2011-06-28 17:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 14:40 [meta-oe][PATCH 0/2] Fix parse errors Otavio Salvador
2011-06-28 14:40 ` [meta-oe][PATCH 1/2] systemd: set all packages PACKAGE_ARCH to MACHINE_ARCH Otavio Salvador
2011-06-28 14:40 ` [meta-oe][PATCH 2/2] task-x11: " Otavio Salvador
2011-06-28 14:51 ` [meta-oe][PATCH 0/2] Fix parse errors Koen Kooi
2011-06-28 14:59 ` Otavio Salvador
2011-06-28 15:35 ` Koen Kooi
2011-06-28 16:25 ` Otavio Salvador
2011-06-28 16:49 ` Koen Kooi
2011-06-28 16:54 ` Otavio Salvador
2011-06-28 17:16 ` Tom Rini
2011-06-28 17:46 ` Otavio Salvador
2011-06-28 17:14 ` Frans Meulenbroeks
2011-06-28 17:20 ` Tom Rini [this message]
2011-06-28 17:55 ` Frans Meulenbroeks
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=4E0A0D7B.3000602@mentor.com \
--to=tom_rini@mentor.com \
--cc=openembedded-devel@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.