Openembedded Core Discussions
 help / color / mirror / Atom feed
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





  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