[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