[LEDE-DEV] externalizing package management?

Oswald Buddenhagen oswald.buddenhagen at gmx.de
Wed Jan 11 14:37:37 PST 2017

On Wed, Jan 11, 2017 at 11:00:04AM +0100, Jo-Philipp Wich wrote:
> > in my understanding, sysupgrade images (and uimages) are a pretty
> > uniform archive format,
> Actually they're not. There are factory and sysupgrade images which are
> renamed tars, there are trx images, there are FIT images, proprietary
> vendor formats, images containing images and whole lot of other types.
well, that complicates things a bit.
but somehow sysupgrade itself is able to deal with them. so the
worst-case appears to be that the image wouldn't be re-packed, and thus
end up bigger than if it would be actually created from scratch. that's
not worse than if the packages are installed manually.
or am i missing some relevant detail again?

> > a single generic tool should be able to work with all targets, over
> > extended periods of time, and would need to support a rather limited
> > number of features to accomplish the goal of building images from the
> > "regular" image+package downloads that are already available.
> The only real solution is something GNU make based in order to be able
> to re-use the image format knowledge encoded in the per target
> Makefiles. Anything else requires duplication of the image build logic
> which can, and will, quickly diverge from whats in Master.
actually, not the only solution: it's also possible to use a yet
higher-level description, and generate makefile fragments from that.
if this was abstract enough, it could be used as a recipe for unpacking
the images as well, without specifying it separately. obviously, the
backends would need to duplicate the available transforms, but the
amount of work required doesn't seem _extraordinary_ if the goal is
deemed worthwhile.

More information about the Lede-dev mailing list