Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes: > On Tue, Jan 26, 2021 at 06:49:03PM -0500, Greg Troxel wrote: >> [...] >> I also don't understand why xentools413 doesn't build on 9.0, but my > > because 9.0 doesn't have the needed defines in /usr/include/xen/ > > Anyway it was failing on pkgbuild not because the build env isn't up > to date (it is) but because we're using libkvers to pretend we are 9.0, > and so the ONLY_FOR_PLATFORM check didn't pass. > > I patched the Makefile locally and not is it built. I think we need to step back and think about the overall approach here: I'm not sure we should be faking for 9.0. My take is that everybody should be up to date on netbsd-9, and certainly upgrade to minor releases. So therfore we should optimize for those who are up to date, not those who are behind. That leads to updating the build systems along netbsd-9 whenever there is a good reason and setting libkver to 9.1, regardless of anything else. But I may be missing something. It's more important that things build where they can than getting a nice failure where they don't. So given that people use libkver, I don't think something that is ok on up-to-date netbsd-9 should be marked as BROKEN/NOT_FOR for 9.0. Similarly for current; the only supported current in pkgsrc is current current and I don't think it matters what happens if someone tries pkgsrc HEAD on current from even 6 months ago. Definitely pkgsrc should be set up to succeed when anyone configures bulk builds, without any changes. So that leads to two changes: Simplify ONLY_FOR_PLATFORM in xentools413 to be for all of NetBSD 9 and 9.99 and if it fails on old systems so be it, and pullup. This fixes the immediate issue. I don't see any reason not to do this. Consider setting libkver on pkgbuild to 9.1, (or letting it be 9_STABLE).
Attachment:
signature.asc
Description: PGP signature