Stefan Hagen <sh+openbsd-t...@codevoid.de> wrote:
> Andrew Hewus Fresh wrote (2022-02-28 15:40 CET):
> > On Mon, Feb 28, 2022 at 02:47:24PM +0100, Stefan Hagen wrote:
> > > But now I see that NEXT_VERSION is set earlier and this should fix it:
> > >
> > > -if $RELEASE && [[ ${_KERNV[1]} == '-beta' ]]; then
> > > +if $RELEASE || [[ ${_KERNV[1]} == '-beta' ]]; then
> >
> > It would fix this particular case, but this code is here for the
> > situation where:
> >
> > A user is on 7.1-beta, 7.1 is release and the user does `sysupgrade -r`
> >
> > This patch would break that case. I will keep thinking on a proper
> > fix.
>
> Are you sure?
>
> I made myself a small table with the possible upgrade paths how I
> see them:
>
> Source rel. | Target rel. | Firmware dir.
> ------------+-------------+----------------
> 7.0-release | 7.1-release | ${NEXT_VERSION}
> 7.0-release | 7.1-beta | ${NEXT_VERSION}
> 7.0-release | 7.0-current | snapshots
> -
> 7.0-current | 7.1-release | ${NEXT_VERSION}
> 7.0-current | 7.1-beta | ${NEXT_VERSION}
> 7.0-current | 7.0-current | snapshots
> -
> 7.1-beta | 7.1-release | ${_KERNV[0]}
> 7.1-beta | 7.1-beta | ${_KERNV[0]}
> 7.1-beta | 7.1-current | snapshots
>
> If you don't look at the release/beta/current tags and compare the
> release version number instead, it gets simpler:
>
> source_VER == target_VER: ${_KERNV[0]}
> source_VER != target_VER: ${NEXT_VERSION}
> both overruled by -current: snapshots
>
> Regarding the regex: The output of
> sysctl -n kern.version
> is the same as
> echo exit | config -eo /dev/null bsd
>
> So the regex used to parse the information for _KERN can be reused.
That sounds right to me.
