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
WARNING: multiple messages have this Message-ID (diff)
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: 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: 23+ 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 10:13 ` Alex J Lennon
2014-08-07 13:05 ` [yocto] " Paul Eggleton
2014-08-07 13:05 ` Paul Eggleton
2014-08-07 13:14 ` [yocto] " Alex J Lennon
2014-08-07 13:14 ` Alex J Lennon
2014-08-08 7:54 ` [yocto] " Nicolas Dechesne
2014-08-08 7:54 ` Nicolas Dechesne
2014-08-08 15:57 ` [yocto] " Alex J Lennon
2014-08-08 15:57 ` Alex J Lennon
2014-08-12 13:23 ` [OE-core] " Tim O' Callaghan
2014-08-09 8:13 ` [yocto] " 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-07 12:09 ` Bryan Evenson
2014-08-08 8:04 ` Nicolas Dechesne
2014-08-08 8:04 ` [OE-core] " Nicolas Dechesne
2014-08-25 6:47 ` Paul Eggleton
2014-08-25 6:47 ` [OE-core] " Paul Eggleton
2014-08-08 12:56 ` Mike Looijmans
2014-08-08 12:56 ` [OE-core] " 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 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.