In D44560#1028474, @arrowd wrote:

Meanwhile, the upstream accepted my patch: https://github.com/dotnet/runtime/pull/100731

In D44560#1018481, @arrowd wrote:

In D44560#1018480, @zirias wrote:

• It will expect dotnet installed in ${LOCALBASE}/share/dotnet while the port currently installs to ${LOCALBASE}/dotnet, is this intentional?

Hmm, I was just following other cases around that code. Maybe it is our port that should be changed to install into share?

Regarding the upstream PR, that certainly is the path to a "correct" solution! Two remarks though:

Maybe my text for pkg-descr wasn't the best ... but first, I'm unsure about this patch as well, it's a separate review for a strong reason here ;)

In D44561#1017694, @arrowd wrote:

I'm again not sure about post-install part. I think something should be patches in the runtime code to look in the location suitable for FreeBSD.

My PowerShell port seems to finally work: https://people.freebsd.org/~zirias/patches/0001-shells-powershell-Add-new-port.patch
Maybe it's a nice testcase here.

In D44560#1016150, @arrowd wrote:

With our Linuxulator technology we might be actually able to run both Linux and FreeBSD binaries. I'll look into that.

In D44560#1016148, @arrowd wrote:

Hum, aren't compilation products of .NET intended to be cross-platform?

In D44560#1016146, @arrowd wrote:

Maybe we can at least persuade upstream to look for $LOCALBASE/etc/dotnet/install_location

The thing is that this won't solve anything for precompiled stuff, but see my comment above: Probably pointless anyways because anything precompiled will always have some native stub code not built for FreeBSD...

In D44560#1016144, @zirias wrote:

This won't help when users download some binary (IL) software and try to run it, it will have /usr/share/dotnet and this config file "baked in", so I really think just adding this file is the portable solution.

In D44560#1016142, @arrowd wrote:

can be reproduced with the simplest possible helloworld project:

Great, this is exactly what I asked for, many thanks! I'll play with runtime to make this testcase to work out of the box.

Just tried, can be reproduced with the simplest possible helloworld project:

You'll just need some dotnet software built without using options like PublishReadyToRun, PublishAOT, PublishSingleFile ...

In D44560#1016136, @arrowd wrote:

Can you please elaborate a bit on what problem does this change solve?

I totally forgot I was still waiting for maintainer approval on this one. Now it finally popped up in my builds again, so updated and rebased.

Thanks a lot again, please

Thanks for this! It seems I goofed here a long time ago when I ported the existing Linux driver to FreeBSD, the original code *does* error-check copy_[from|to]_user().

In D42890#978172, @jbo wrote:

Note: GCC versions 8 and 9 have been removed from GNU_COMPILERS because they are marked deprecated in the ports tree and will expire at 2023-12-31 and 2024-06-30 respectively

Having another look was very helpful, turned out the few ENGINE_* calls LibreSSL *does* provide are just stubs returning NULL. Even code disabling engines based on the OPENSSL_NO_ENGINE feature flag was already there, it just didn't work because opensslconf.h was not included, which is necessary at least with LibreSSL to get the feature flags. This might even be a fix for upstream now ...

Can't use the *_WITH helper when multiple options handle the same configure knob, d'oh, fixed.

recommend to commit the patch from the PR directly after that, hereby approved as well.

rebase on updated parent revision

Remove the emptyok option to really treat both possible ways of storing an "empty" password the same. I think everything else would be confusing and bear the risk of misconfiguration.

I just noticed I broke the already existing emptyok option with this. I'm not sure whether it's a good idea to distinguish them at all, but they're certainly used in an inconsistent way: During password change, whether an empty password will be allowed depends on nullok (line 390), nevertheless a hash will be stored, matching the "empty" password.

ok then,

It also serves a purpose for people actually using a root shell, but prefer one from ports. Then it's helpful to have a simple fallback with a shell from base in case of emergency. When you look at discussions on FreeBSD forums, this seems to be a somewhat popular use case.