On Thu, Aug 7, 2014 at 3:05 PM, Paul Eggleton <paul.eggle...@linux.intel.com> wrote: > Personally with how fragile package management can end up being, I'm convinced > that full-image updates are the way to go for a lot of cases, but ideally with > some intelligence so that you only ship the changes (at a filesystem level > rather than a package or file level). This ensures that an upgraded image on > one device ends up exactly identical to any other device including a newly > deployed one. Of course it does assume that you have a read-only rootfs and > keep your configuration data / logs / other writeable data on a separate > partition or storage medium. However, beyond improvements to support for > having a read-only rootfs we haven't really achieved anything in terms of out- > of-the-box support for this, mainly due to lack of resources. > > However, whilst I haven't had a chance to look at it closely, there has been > some work on this within the community: > > http://sbabic.github.io/swupdate/swupdate.html > https://github.com/sbabic/swupdate > https://github.com/sbabic/meta-swupdate/ >
fwiw, Ubuntu has started to do something like that for their phone images, see https://wiki.ubuntu.com/ImageBasedUpgrades I haven't used nor looked into the details... i just had heard about it, and thought it was worth mentioning it here. however the main design idea from that wiki page is exactly what we are discussing here. e.g. build images on the 'server' side using our regular tools, but deploy binary differences on targets. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
