Antoine Jacoutot writes: > That is because 001 only includes kernel object files which you do not have > since you run under a chroot and didn't extract /usr/share/relink/kernel.tgz > So syspatch(8) considers you don't have that "set" installed. > syspatch-003 on the other end includes a header change and that header *is* > installed on your system. So syspatch installs it. But you are missing all the > other pieces to actually relink your kernel and that's why it fails.
Thank-you that makes sense. It did throw me a little though; I would expect a tool such as this to report its inaction as well as its action. I take it that syspatch performs these checks also with the other sets? eg. It would skip an X patch if the X sets were not installed? > You are running syspatch under a totally unsupported setup. This is a common refrain and I do understand why it's used but it's not a concern. I'm not after support, I can put the pieces back together when I break them. But is 'all the sets' the only configuration which OpenBSD's tools consider valid in general? 'Supported'? In any case I still do think there's a bug here but now it's clear that it's one of: * syspatch doesn't report skipping patches (it also skipped a kernel patch when it recognised the lack of kernel but attempted to relink it later anyway for another patch, which will boil down to the same test). * syspatch's manpage doesn't fully describe its behaviour when one or more sets are mising. Please note that I'm not whinging that OpenBSD doesn't work the way I demand and insisting on change. I've noticed there's been a lot of that recently. I've found what I deem to be a fault and, if anyone else agrees, would like suggestions on how I could fix it (chiefly, which of the above is the real bug) and I will follow up with a patch. Or neither and I'll just deal with it locally. Matthew
