I stopped reading as soon as your pride showed.
Eponymous Pseudonym <suomyn...@gmail.com> wrote: > 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. > > >
