[LEDE-DEV] externalizing package management?

Stefan Lippers-Hollmann s.l-h at gmx.de
Sun Jan 8 05:16:55 PST 2017


Hi

On 2017-01-08, Oswald Buddenhagen wrote:
> moin,
> 
> openwrt aims to be a "proper" linux distribution, and therefore comes
> with on-device package management.
> 
> but we know that to be a problem for the more space-constrained devices.
> also, the space constraints make the package manager pretty dumb by
> modern standards. both issues have been raised in recent threads.
> 
> so how about optionally externalizing (package) management?
> 
> a typical admin session would look like this:
> - select target device
> - sync with device
>   - to connect with pre-existing devices.
>   - to still support direct on-device modifications, though it's
>     conceivable to build images which don't provide the tools for that.
>   - to support multiple management machines, even if realistically
>     speaking most devices are administered from a single desktop/laptop
>     anyway.
> - do modifications with powerful desktop tools
> - sync back to device
>   - individual files
>   - or create and flash image
> - tell device to reboot, or at least (re-)load some services (the latter
>   is obviously a lot more work to implement)

Using imagebuilder (and keeping the existing configs, which is the 
default for sysupgrade) seems to tick all of your boxes, doesn't it?

> the syncing itself should be probably just done via ssh (mostly fish, as
> known from midnight commander), as it also offers the option to invoke
> sysupgrade, reboot, and to start/reload services without using an
> additional protocol.

Even if you use imagebuilder, nothing prevents you from doing manual
changes on top, using plain scp/ sftp compatible tools.

> with this concept, it would be also possible to integrate the
> kernel/rootfs into the package management, which would improve
> usability. and obviously, it would nicely solve the system upgrade
> problem, which is how i arrived here in the first place.

Same here, sysupgrade images do update the kernel as well, so where's
the functional difference between the status quo (using imagebuilder)
and your envisioned plan (other than nomenclature and having to reboot
for 'package updates' == flashing new/ modified sysupgrade images, but
that's merely an implementation detail and unavoidable if you want/ 
need to make use of squashfs' compression advantage)?

Regards
	Stefan Lippers-Hollmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170108/c4a20348/attachment-0001.sig>


More information about the Lede-dev mailing list