One day I'll write you a newer autonomous back-end.. and mirror propagation signalling / tracker, that is OpenBSD, protocol and CDN independent.. but that is probably not needed for now.
It's true, not relying on sysupgrade(8) for a long time before it showed up, and a lot other things, but it should not stop me from suggesting a minor fix here and there if it's going to help others. If it's a time waste, so be it. I'm happy with conveniences and OpenBSD proposed scripts anyway. Hence suggesting the sets enum etc.. I still think the suggestions are not that difficult or bad of ideas, though. If you don't like these, I do not insist. Your call, I just said a couple of words that do not matter much to you, it seems. Didn't mean to upset anyone (this time). And it's vanity, not pride, but those are not my qualities, despite what it looks like from your viewpoint. When I suggest something the next time, it will not be self-deprecating again but might lack the commentaries. I'm not going to speak in the third person, even if you need it for submissions. Now I'll stop reading too. On 9/26/23, Theo de Raadt <dera...@openbsd.org> wrote: > 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. >> > >> >
