Updated the diff using arcanist, as using raw diff upload the way I did won't get us far.

This isn't simply about host not matching the jail. It's more nuanced. The jail may not match the jail. If people don't understand that I am strongly against anything like this going in. But what do I care if you shoot yourselves in the foot?

In D30239#679284, @bdrewery wrote:

This isn't simply about host not matching the jail. It's more nuanced. The jail may not match the jail.

Does this change anything about the patch though (which in the end implements a force flag, which isn't nuanced at all)? Would you prefer a different name of the flag that emphasizes that you think this error shouldn't be ignored?

If people don't understand that I am strongly against anything like this going in. But what do I care if you shoot yourselves in the foot?

That's the very nature of providing force/override/ignore warning flags, people using them are on their own. This was raised by a couple of experienced engineers, who have their workflows disrupted by the current state of affairs.

As long as the default behavior doesn't change and therefore things stay safe for normal ports tree users, I don't see any negative consequences. People will shoot themselves in the foot anyway by patching the file manually, so having a flag will at least make sure they don't start using diverging local copies of bsd.port.mk.

I have no personal interest in this beyond trying to direct our energy towards more productive discussions, this doesn't seem like something worth fighting over and being subjected to a lot of negativity in the process.

I sympathize with having to field support requests of people shooting themselves in the foot. That said, there can be valid reasons to for example try a newer kernel w/o updated userland to see whether a regression was fixed. In that instance I would like (have to, really) build a new drm-kmod-current package which this check prevents me from doing.

Adding an ALLOW_OSVERSION_MISMATCH seems like a good workaround for that, no?

Just to repeat an earlier comment and asking portmgr to comment - then this review can progress or be abandoned and either way there will be a documented decision.

In D30239#679354, @grembo wrote:

In D30239#679284, @bdrewery wrote:

This isn't simply about host not matching the jail. It's more nuanced. The jail may not match the jail.

Does this change anything about the patch though (which in the end implements a force flag, which isn't nuanced at all)? Would you prefer a different name of the flag that emphasizes that you think this error shouldn't be ignored?

If people don't understand that I am strongly against anything like this going in. But what do I care if you shoot yourselves in the foot?

That's the very nature of providing force/override/ignore warning flags, people using them are on their own. This was raised by a couple of experienced engineers, who have their workflows disrupted by the current state of affairs.

My perspective is that we have re@ trying to use it without understanding the problem. It should not be used for any official builds.

As long as the default behavior doesn't change and therefore things stay safe for normal ports tree users, I don't see any negative consequences. People will shoot themselves in the foot anyway by patching the file manually, so having a flag will at least make sure they don't start using diverging local copies of bsd.port.mk.

I have no personal interest in this beyond trying to direct our energy towards more productive discussions, this doesn't seem like something worth fighting over and being subjected to a lot of negativity in the process.

The negativity is because the problem has not been understood since the check went in which has built up frustration over years, and now there is screaming to remove or allow disabling still without understanding the problem which is causing me to get frustrated. Misunderstandings breed frustration. Now everyone is frustrated. Let's slow down and try to understand.

Hopefully this clears up the problem:

• When building a port it is possible for it to run uname to determine its target system (edit: and bake in different target runtime behavior). If that is coming back not matching the userland of the chroot/jail, how is that _ever ok_? 3rd party ports are far more likely to care about uname than __FreeBSD_version or any other FreeBSD-specific version lookup.
• OSVERSION can probably always be determined automatically. A user does not need to mess with it so long as /usr/include/sys/param.h has a __FreeBSD_version that is expected for the target system.
• OSVERSION ultimately determines *Ports framework behavior* and which patches are applied. It needs to be correct for the target system.
• The only thing that someone trying to build in a chroot must do is ensure UNAME_r is correct.
  • Explain to me why it is easier for them to set ALLOW_OSVERSION_MISMATCH rather than modifying UNAME_r once every 2-3 years or making their chroot setup script do it auto based on git branch or something?
• UNAME_r could probably be automatically determined from OSVERSION. That is a more sane proposal rather than ignoring the problem but I haven't thought deeply about it yet.

Please, anyone, explain to me why my points are wrong.

Please, anyone, explain to me what I am missing.

In D30239#690366, @bdrewery wrote:

In D30239#679354, @grembo wrote:

In D30239#679284, @bdrewery wrote:

This isn't simply about host not matching the jail. It's more nuanced. The jail may not match the jail.

Does this change anything about the patch though (which in the end implements a force flag, which isn't nuanced at all)? Would you prefer a different name of the flag that emphasizes that you think this error shouldn't be ignored?

If people don't understand that I am strongly against anything like this going in. But what do I care if you shoot yourselves in the foot?

That's the very nature of providing force/override/ignore warning flags, people using them are on their own. This was raised by a couple of experienced engineers, who have their workflows disrupted by the current state of affairs.

My perspective is that we have re@ trying to use it without understanding the problem. It should not be used for any official builds.

As long as the default behavior doesn't change and therefore things stay safe for normal ports tree users, I don't see any negative consequences. People will shoot themselves in the foot anyway by patching the file manually, so having a flag will at least make sure they don't start using diverging local copies of bsd.port.mk.

I have no personal interest in this beyond trying to direct our energy towards more productive discussions, this doesn't seem like something worth fighting over and being subjected to a lot of negativity in the process.

The negativity is because the problem has not been understood since the check went in which has built up frustration over years, and now there is screaming to remove or allow disabling still without understanding the problem which is causing me to get frustrated. Misunderstandings breed frustration. Now everyone is frustrated. Let's slow down and try to understand.

Hopefully this clears up the problem:

• When building a port it is possible for it to run uname to determine its target system (edit: and bake in different target runtime behavior). If that is coming back not matching the userland of the chroot/jail, how is that _ever ok_? 3rd party ports are far more likely to care about uname than __FreeBSD_version or any other FreeBSD-specific version lookup.
• OSVERSION can probably always be determined automatically. A user does not need to mess with it so long as /usr/include/sys/param.h has a __FreeBSD_version that is expected for the target system.
• OSVERSION ultimately determines *Ports framework behavior* and which patches are applied. It needs to be correct for the target system.
• The only thing that someone trying to build in a chroot must do is ensure UNAME_r is correct.
  • Explain to me why it is easier for them to set ALLOW_OSVERSION_MISMATCH rather than modifying UNAME_r once every 2-3 years or making their chroot setup script do it auto based on git branch or something?
• UNAME_r could probably be automatically determined from OSVERSION. That is a more sane proposal rather than ignoring the problem but I haven't thought deeply about it yet.

Please, anyone, explain to me why my points are wrong.

Please, anyone, explain to me what I am missing.

A build failure should not be the default case when building within a chroot(8) that does not match the running kernel. To quote Doug Barton, "tools, not policy."

If I have a build host running 14.0-CURRENT and a jail running 13.0-STABLE, my expectation is that I should be able to build *anything* for 13.0, world, kernel, and ports, without a hard failure due to a silly constraint enforced in the tree.

If I know what I am doing, I should be able to shoot myself in the foot and deal with the consequences. This is UNIX. As I said before:

"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." -Doug Gwyn

Also note, official release builds do not happen on mismatched userlands/kernels. They are built on machines running the same major OSVERSION/UNAME_r as the target release.

@bdrewery But don't you think that

1. A feature request from an important consumer of the ports collection should be considered;
2. There is a large number of ports where none of this (uname, osversion, etc.) matters anyway, at least in a development environment;
3. It's better to be able to clearly express "I'm willing to allow a mismatch" vs. overriding an environment variable and pretend there is none?

@gjb @bdrewery Can you imagine to agree on some compromise?

In D30239#690405, @grembo wrote:

@bdrewery But don't you think that

1. A feature request from an important consumer of the ports collection should be considered;
2. There is a large number of ports where none of this (uname, osversion, etc.) matters anyway, at least in a development environment;
3. It's better to be able to clearly express "I'm willing to allow a mismatch" vs. overriding an environment variable and pretend there is none?

@gjb @bdrewery Can you imagine to agree on some compromise?

I just want to be able to build weekly snapshots without adding hacks around other hacks to trick the bsd.ports.mk into thinking "everything is fine" by overriding OSVERSION and UNAME_r.

But, for now, I've solved that problem in a different way - we are no longer having stable/11 snapshots, as I upgraded the builders accordingly.

So, "policy" has overruled "tools" for the moment, at the expense of losing snapshots for a supported stable branch.

I've added a foot shooter in https://cgit.freebsd.org/ports/commit/?id=154492dd1f1d8c9a8f9c283f830a737c96e64a10

I understand that people want to just chroot /some/path make -C myport but that's not a sufficient build environment setup for ports where there are 30k+ random 3rd party things that may run uname. Yes your port may be special but the common case is not your port.

The reason I made this commit today was because a Poudriere user, not as described in the commit message, had a port overwriting /etc/make.conf which blew away the UNAME_r setting. This was hidden in a dependency. Subsequent ports that installed that dependency suddenly were trying to target the wrong release. This only validates my POV. Are you seriously going to tell me that a) the user knew better or b) that this should silently corrupt their packages or c) that some ignorant-but-good-intending user who suggests to set ALLOW_OSVERSION_MISMATCH in make.conf to workaround the problem wouldn't happen and cause them hidden problems?
I knew of the reason explained in the commit message (poudriere downgrade) prior to today from my own Poudriere testing accidentally running into it. Again this check that has been in there saved the day for me running into silent problems and validated my reasoning there too.
It has saved me at work before as well where we do cross-os-release builds and have to define the UNAME_* stuff anyway.

I chose to call it that because the flag IS DANGEROUS in the common case. The flag reflects the outcome if it is used and not understood. Anything benign is an open invitation for [not people here] ignorant users to use or suggest it.

A feature request from an important consumer of the ports collection should be considered;

The more reasonable feature would be to simply auto determine UNAME_r from OSVERSION which I will think more seriously about.

In D30239#710983, @bdrewery wrote:

It has saved me at work before as well where we do cross-os-release builds and have to define the UNAME_* stuff anyway.

I chose to call it that because the flag IS DANGEROUS in the common case. The flag reflects the outcome if it is used and not understood. Anything benign is an open invitation for [not people here] ignorant users to use or suggest it.

While I understand your hesitancy and due dilligence in preventing people from foot-shooting, I do appreciate you adding a knob to allow those that intentionally and knowingly to do so.

For my particular use case, just as an example, I had to stop building stable/11 snapshots because:

• The builder for 13.x and 14.x needed to be upgraded to a more recent 13.x;
• Out of frustration, I upgraded the 13.x/14.x to -CURRENT
• The upgrade prevented 13.x builds from succeeding, whereas the opposite was true before the upgrade, presumably due to a syscall addition;
• Out of frustration, I upgraded all of the other builders accordingly, building 14.x, 13.x, and 12.x.
• As (prior to your change) stable/11 ports would not longer build on the 12.x builder, I decided I was done fighting with this problem.

Take into consideration, for example, a case where I *really* do not care that the userland and kernel are mismatched. Ports kmods are not built for snapshot/release builds on these machines.

When building devel/git, net/bsdec2-image-upload, GCE dependencies, or whatever, I do not care if the userland/kernel are mismatched, because I do not need to care.

A feature request from an important consumer of the ports collection should be considered;

The more reasonable feature would be to simply auto determine UNAME_r from OSVERSION which I will think more seriously about.

I tried hacking release.sh to accomodate exactly this, and it turned into a deeper rabbit hole than I had hoped.

All that said, thank you again for making this change.

In D30239#710984, @gjb wrote:

Thank you for the detailed explanation. I understand I am hard to deal with on this. I think upon human behavior sporadically and it is impossible for us to communicate our true thoughts, beliefs, or assumptions, or to easily break out of our own perspectives or assumptions. Especially over body-free text. I will try to communicate here in a way that avoids those pitfalls. Please do the same and assume I am asking innocently questions. I only wish I could always have this mindset in text. I'm only saying all of this because I've personally gotten frustrated over this discussion a lot and I'm trying to approach it differently after discussion with the Poudriere user post-commit.
I like to understand things at too deep a level sometimes, in that I need to know the root cause. I suppose I prefer quicker paced communications like IRC, or a call, to get the details out, versus this back and forth mailing list thing we've been doing. I should have asked for details or listened better in the past, like 8 years ago or whenever you ran into it.

• The builder for 13.x and 14.x needed to be upgraded to a more recent 13.x;
• Out of frustration, I upgraded the 13.x/14.x to -CURRENT
• The upgrade prevented 13.x builds from succeeding, whereas the opposite was true before the upgrade, presumably due to a syscall addition;
• Out of frustration, I upgraded all of the other builders accordingly, building 14.x, 13.x, and 12.x.
• As (prior to your change) stable/11 ports would not longer build on the 12.x builder, I decided I was done fighting with this problem.

If I understand you correctly, you are saying that this error was only thrown once at the end and at the host level and not in an expected cross-build scenario, right?
If I understand you correctly, the host kernel and host userland could have been mismatched while trying to build ports for itself, in the host, right?

Take into consideration, for example, a case where I *really* do not care that the userland and kernel are mismatched. Ports kmods are not built for snapshot/release builds on these machines.

Do you think only kmod ports are a problem for mismatched kernel/userland builds?

When building devel/git, net/bsdec2-image-upload, GCE dependencies, or whatever, I do not care if the userland/kernel are mismatched, because I do not need to care.

Do you care if git were to start crashing when used?

I would like to continue this conversation if you don't mind so I can finally get that aha moment with you and see your POV properly.

I am coming around to the idea of automatically determining UNAME_r if possible before throwing this error. I had not considered people running into this on *host systems*. My strong build-in-jail (poudriere) perspective didn't let that fact come through.

In D30239#710987, @bdrewery wrote:

In D30239#710984, @gjb wrote:

Thank you for the detailed explanation. I understand I am hard to deal with on this. I think upon human behavior sporadically and it is impossible for us to communicate our true thoughts, beliefs, or assumptions, or to easily break out of our own perspectives or assumptions. Especially over body-free text. I will try to communicate here in a way that avoids those pitfalls. Please do the same and assume I am asking innocently questions. I only wish I could always have this mindset in text. I'm only saying all of this because I've personally gotten frustrated over this discussion a lot and I'm trying to approach it differently after discussion with the Poudriere user post-commit.
I like to understand things at too deep a level sometimes, in that I need to know the root cause. I suppose I prefer quicker paced communications like IRC, or a call, to get the details out, versus this back and forth mailing list thing we've been doing. I should have asked for details or listened better in the past, like 8 years ago or whenever you ran into it.

You are not at all difficult to deal with, as far as I am concerned. I hope you know that from some of our past exchanges. And you have my phone number, so if you feel we are starting to get too far into the weeds on things like this, just call me. And I mean that.

[...]

If I understand you correctly, you are saying that this error was only thrown once at the end and at the host level and not in an expected cross-build scenario, right?

Let's not conflate the definition of "cross-build". To me, "cross-build" means "building one architecture on a different architecture, i.e., aarch64 on amd64." In that case, no, that is not the problem.

If, however, you mean building 13.x on a machine running 14.x, then yes, that is the problem being encountered.

If I understand you correctly, the host kernel and host userland could have been mismatched while trying to build ports for itself, in the host, right?

No, this is not the case. The scenario is building a port within a chroot for use within the chroot where it is expected that the userland within the chroot should be able to build/run a particular binary. On stable branches, we forbid (as much as possible) ABI/API changes, so I should be able to run a binary from 12.0 on 12.2, for example. I should not need to care if the XXXYYZZZ __FreeBSD_version (i.e., 14000029) does not match 14000028.

Take into consideration, for example, a case where I *really* do not care that the userland and kernel are mismatched. Ports kmods are not built for snapshot/release builds on these machines.

Do you think only kmod ports are a problem for mismatched kernel/userland builds?

Absolutely not. I know sysutils/lsof is problematic here, as well as many other ports that depend on the kernel/userland being in sync.

When building devel/git, net/bsdec2-image-upload, GCE dependencies, or whatever, I do not care if the userland/kernel are mismatched, because I do not need to care.

Do you care if git were to start crashing when used?

Of course I do. But upgrading the builder for an unrelated __FreeBSD_version bump is overkill, in my opinion.

I would like to continue this conversation if you don't mind so I can finally get that aha moment with you and see your POV properly.

Again, you have my phone number. I am happy to discuss this further out-of-band and come back to this review thread afterward with what we have discussed.

And to be clear, I am not trying to be difficult at all. The UNAME_r versus OSVERSION change was initially a non-issue for me, as I was able to override UNAME_r for my specific use case. But when comparing them in reverse (OSVERSION versus UNAME_r) was implemented, that is where it became a problem.