From: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: yocto@yoctoproject.org, openembedded-core@lists.openembedded.org
Subject: Re: [yocto] RFC: Improving the developer workflow
Date: Thu, 07 Aug 2014 11:13:02 +0100 [thread overview]
Message-ID: <53E3512E.5090008@dynamicdevices.co.uk> (raw)
In-Reply-To: <1571948.CrPtZqAbFm@peggleto-mobl5.ger.corp.intel.com>
On 07/08/2014 10:10, Paul Eggleton wrote:
> Hi folks,
>
> As most of you know within the Yocto Project and OpenEmbedded we've been
> trying to figure out how to improve the OE developer workflow. This potentially
> covers a lot of different areas, but one in particular I where think we can
> have some impact is helping application developers - people who are working on
> some application or component of the system, rather than the OS as a whole.
>
> Currently, what we provide is an installable SDK containing the toolchain,
> libraries and headers; we also have the ADT which additionally provides some
> Eclipse integration (which I'll leave aside for the moment) and has some
> ability to be extended / updated using opkg only.
>
> The pros:
>
> * Self contained, no extra dependencies
> * Relocatable, can be installed anywhere
> * Runs on lots of different systems
> * Mostly pre-configured for the desired target machine
>
> The cons:
>
> * No ability to migrate into the build environment
> * No helper scripts/tools beyond the basic environment setup
> * No real upgrade workflow (package feed upgrade possible in theory, but no
> tools to help manage the feeds and difficult to scale with multiple releases and
> targets)
>
Very interesting Paul.
fwiw Upgrade solutions are something that is still a read need imho, as
I think we discussed at one of the FOSDEMs.
(The other real need being an on-board test framework, again imho, and
which I believe is ongoing)
Historically I, and I suspect others, have done full image updates of
the storage medium, onboard flash or whatever but these images are
getting so big now that I am trying to move away from that and into
using package feeds for updates to embedded targets.
My initial experience has been that
- as you mention it would be really helpful to have something "more"
around management of package feed releases / targets.
- some automation around deployment of package feeds to production
servers would help, or at least some documentation on best practice.
The other big issue I am seeing, which is mostly my own fault thus far,
is that I have sometimes taken the easy option of modifying the root
filesystem image in various ways within the image recipe (for example
changing a Webmin configuration perhaps)
However when I then come to upgrade a package in-situ, such as Webmin,
the changes are then overwritten.
I think this is probably also an issue when upgrading packages that have
had local modifications made, and I wonder whether there's a solution to
this that I'm not aware of?
I am aware of course that mainstream package management tools allow
diffing, upgrading, ignoring and such but I am unsure as to how that is
supported under Yocto at present?
As a minimum I will have to make sure my OEM recipe changes are all in
the correct .bbappends I believe think (more best practice notes there)
and I definitely need to understand better how configuration file
changes are handled when upgrading packages.
Cheers,
Alex
next prev parent reply other threads:[~2014-08-07 10:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-07 9:10 RFC: Improving the developer workflow Paul Eggleton
2014-08-07 10:13 ` Alex J Lennon [this message]
2014-08-07 13:05 ` [yocto] " Paul Eggleton
2014-08-07 13:14 ` Alex J Lennon
2014-08-08 7:54 ` Nicolas Dechesne
2014-08-08 15:57 ` Alex J Lennon
2014-08-09 8:13 ` Mike Looijmans
2014-08-09 8:44 ` Alex J Lennon
2014-08-09 11:22 ` Mike Looijmans
2014-08-09 11:57 ` Alex J Lennon
2014-08-08 8:04 ` Nicolas Dechesne
2014-08-25 6:47 ` Paul Eggleton
2014-08-08 12:56 ` Mike Looijmans
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=53E3512E.5090008@dynamicdevices.co.uk \
--to=ajlennon@dynamicdevices.co.uk \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
--cc=yocto@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