On Fri, Jun 07, 2019 at 02:49:32AM +0300, cho...@jtan.com wrote:
> 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?
Yes that's correct.
> > 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'?
Well, it's not really about the sets.
>From the man page:
CAVEATS
syspatch is designed to work solely on official OpenBSD releases.
What you are running is not.
An official release comes with a kernel.
One can skip a set but if I think it's fair for the tools to assume one has
at least one kernel and baseXX installed...
> 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).
I explained why.
It sees that there's a candidate for replacement (in this case some headers), so
it extracts the patch. Since it also contains kernel objects files, it will run
reorder_kernel, but you didn't extract the release object files in your chroot
(which the installer does)... so boom.
> * syspatch's manpage doesn't fully describe its behaviour when one or more
> sets are mising.
We accept patches for man pages :-)
> 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.
Documentation is clear that syspatch only works on releases. Your chroot is not
because you didn't extract some sets from the baseXX set (and again, IMHO it's
fine for our tools to assume you have at least that particular set installed).
--
Antoine
