Right, that's exactly it. I also found out moments after I posted a white space nuisance, and the logic details that are not enough in what I proposed as it's not factoring the snapshot independently of -release, and also -current and -stable cases are incomplete too, and BEFORE that, there is missing information from, and changes needed too, on the master "release" preparation side.
So can't solve it as simple as I proposed, and was trying to make it a recurring set of state table changes and various "edge" case fixes by iterative incremental sequence of "improvements" that would be always correct regardless of the failure state, even when the index / checksum has been mixed and incompletely overlapped.. but you're relieving this for now and that's fine with me. It took me exactly 3 min to solve it in multiple variants my end and I am not being inconvenienced with a tweak per "newvers" change, after all the extensive routes of precise tracking of these in my custom auto-upgrade routines for many years maybe even more than a decade prior to sysupgrade(8) here.. My main critical point is the omission to enumerate the sets in the logic of the sysupgrade(8) script and the gratuitous version detection based on kernel string and checksum/index rather than normalised (tracked) by newvers state published on the mirror (or in the signatures) or carried in the sets versioning information in a specialised format like BUILDINFO, whatever you like. Anyway, it needs a bit of a discussion to which I have not been yet invited, so will defer that to your schedule and preferred solution, needless to say. Thanks for your qualified feedback as usual. On 9/26/23, Theo de Raadt <dera...@openbsd.org> wrote: > Stuart Henderson <s...@spacehopper.org> wrote: > >> > This results in failure to upgrade to a valid snapshot on the mirrors, >> > and users having to wait a new snapshot fanout without mixed sets and >> > checksum files containing both versions (incompletely the older). >> >> I do not agree with "be lenient on what you expect thing that >> used to be popular belief. So IMHO it is better if sysupgrade fails >> when the files in the ftp directory do not match its expectations. > > There are a few different back-end failure modes going on here. It is > more than a mirroring problem. The hash files contain a mix of files. > I think stuart is right -- we are better off just plain failing. One > day I will find time to improve the backend, but that's not now. >
