[OpenWrt-Devel] [RFC PATCH] sysupgrade: introduce compatibility version for devices

Adrian Schmutzler mail at adrianschmutzler.de
Fri Jun 5 15:11:04 EDT 2020


Hi,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> On Behalf Of Henrique de Moraes Holschuh
> Sent: Freitag, 5. Juni 2020 15:50
> To: openwrt-devel at lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [RFC PATCH] sysupgrade: introduce
> compatibility version for devices
> 
> On 05/06/2020 09:27, Bjørn Mork wrote:
> > I wonder if there might be more flexible and user-friendly ways to
> > handle upgrade incompatibilities if we are allowed to use
> > code/metadata from the new image in the sysupgrade process?  Instead
> > of just providing a version number with some simple semantics like you
> > describe, the new image could provide a script snippet or similar
> > which codifies a more precise description of the incompatibility. And
> > even a solution, if there is one.
> 
> A message (or URL?) might be nice, yes.  That's not something we have right
> now...
> 
> > For the DSA example, such a script could (optionally?) move an
> > incompatible config/network out of the way, while leaving all other
> 
> That's typically a job offloaded to /etc/uci-defaults/* from the new
> image, isn't it?   There's a lot of ar71xx -> ath79 handling done that
> way already...

Writing an uci-defaults script is not the problem, but how to get the data from the Make variable.
Of course it would be easy to just have a uci-defaults with the deviating versions, but I try to not define the same value twice, as we will need it in image/Makefile for the SUPPORTED_DEVICES.

> 
> Downgrades are, of course, unsupported.  They could be, but it would waste

Downgrade will follow the same rules as upgrades, I don't think they will need special consideration at all here.

Best

Adrian

> precious flash, it makes more sense to warn users to backup beforehand in
> the LuCI interface (and not mess with sysupgrade itself, which needs to be
> able to **safely** work unattended as well).
> 
> --
> Henrique de Moraes Holschuh
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list