[LEDE-DEV] externalizing package management?

[Oswald Buddenhagen]

On Sun, Jan 08, 2017 at 02:16:55PM +0100, Stefan Lippers-Hollmann wrote:
> Using imagebuilder (and keeping the existing configs, which is the 
> default for sysupgrade) seems to tick all of your boxes, doesn't it?
> 
not quite. obviously, wrapping the image builder into a script solves
the upgrade problem i started out with, and is in fact functionally
equivalent with the browser-based proposal i made (except that it
requires expertize most "regular" users won't have).
however, this thread is concerned with _interactive_ use. the idea is to
make management of the device as comfortable as of a desktop system. the
question how changes are committed to the device is of secondary concern
from a user perspective.

On Sun, Jan 08, 2017 at 02:39:05PM +0100, Stefan Lippers-Hollmann wrote:
> On the other end of the spectrum, high-end (mostly armhf based) devices
> are starting to roll up the market with flash in the multiple hundreds
> or even gigabyte regions[1], finally making full in-place upgrades and 
> on-device package management an option (only limited by opkg's abilities 
> and the in-place upgrade/ downgrade paths provided by the current 
> packaging practices (maintainer scripts, library versioning, etc.), so 
> for these you might even want/ need a(n even) more universal package 
> manager on the devices themselves).
> 
packaging practices aren't a concern here. typically, an upgrade would
start out with creating a new volume inside a CoW file system, doing all
modifications inside it, and later switching to it atomically.
the limiting factor here is the boot loader, as with the above model,
the kernel needs to be within that file system if it's supposed to be
covered as well. a less ambitious approach is deploying the kernel to
separate ubi volumes, which is what is actually already being done by
some devices.