I use Gentoo on a few machines, and I'm confused by what GP says: I have no problems using OpenSSL 3, and the 1.1 releases have been masked (not installable by default) for a while now.

Same here, I'm on OpenSSL 3 and didn't notice the upgrade in any way. Even my Gentoo ppc64le machine is already on version 3.

I'm talking about this:

The following mask changes are necessary to proceed:

(see "package.unmask" in the portage(5) man page for more details)

# required by net-libs/nodejs-20.5.1::gentoo

# required by www-client/firefox-102.15.0::gentoo

# required by @selected

# required by @world (argument)

=dev-libs/openssl-1.1.1v

And many many many more packages. I went through like 20 yesterday and created custom ebuilds without mentions to slot :0= in ebuild, but there is plenty more.

Something seems unusual about your system. Are you using an unusual profile or heavily customized make.conf? net-libs/nodejs-20.5.1 is satisfied with dev-libs/openssl-3.0.10 out of the box here.

I have a fully updated world with a KDE desktop, and don't have OpenSSL 1.1 installed at all.

eselect profile list says I have selected the default one: default/linux/amd64/17.1 (stable) *

I would not say it is something unusual...

But funny thing is that if I emerge that one specific package with -1, it does not pull this dependency. It seems like something broken inside the portage.

I experienced a similar sounding issue, but was able to decipher the blocked emerge output from portage to find that app-crypt/tpm2-tss-engine was blocking the whole system from getting onto openssl-3. Once I dropped tpm2-tss-engine, things went forward swimmingly. No other unmasking/masking of anything was needed.

> I experienced a similar sounding issue

This is why we need Lojban

Please report any incompatible packages or any that need updating. I don't happen to see any open/related bugs for nodejs.

I generaly don't bother reporting errors like this, I just fix it locally and push things into my overlay/forks and I'm done with it.

It might be your local ebuilds that are the cause of your problem.

As an example, here are the versions of firefox, nodejs, and openssl installed on my system:

  $ eix -I  --format '<installedversions:EQNAMEVERSION>' nodejs -o firefox -o dev-libs/openssl
  =dev-libs/openssl-3.1.2
  =net-libs/nodejs-20.5.1
  =www-client/firefox-102.15.0

I have the same nodejs version and firefox version as you, but neither of them require openssl 1.x.

It seems like portage did remember that those packages were built against that openssl version - when running as "emerge -DavuUN @world @system --changed-deps" the problem went away :-)

Probably some caching issue/race condition in portage...

Gentoo is very much alive - from time to time I try some other distro but I keep going back. I do some development and I need headers and generally latest versions of some libraries and in Gentoo this is by default.

In Debian there is no way to do that - and the last time I tried to switch to unstable, my Debian commited suicide :)

Gentoo will never die, as long as users want to tinker (in ways that Arch can't)

OpenSSL 3.x is in Gentoo, but isn't marked stable for general use yet due to the number of packages still supported that break under it

OpenSSL 3.0.x (3.0.9 and 3.0.10) seems to be marked as stable on my amd64 system, and 1.0.x is masked:

  $ eix -I dev-libs/openssl | grep -e 'Available versions:'
       Available versions:  [M]1.0.2u-r1^td [M]1.1.1u(0/1.1)^t [M](~)1.1.1v(0/1.1)^t 3.0.9-r1(0/3)^t 3.0.9-r2(0/3)^t 3.0.10(0/3)^t (~)3.1.1-r1(0/3)^t (~)3.1.1-r2(0/3)^t (~)3.1.2(0/3)^t {+asm bindist fips gmp kerberos ktls rfc3779 sctp sslv2 (+)sslv3 static-libs test tls-compression (+)tls-heartbeat vanilla verify-sig weak-ssl-ciphers ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_X86="sse2"}

3.0.x is even stable on my ppc64le system, didn't even notice the upgrade.

It's definitely marked as stable, everything else is masked.