[Bug 268540] emulators/linux-c7 have too old GLIBC for some software: /lib64/libc.so.6: version `GLIBC_2.26' not found (required by lwjgl/3.3.1-build-7/liblwjgl.so)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268540

--- Comment #21 from Gleb Popov <arrowd@FreeBSD.org> ---
(In reply to Alexander Leidinger from comment #19)

Thanks for the review.

> pulseaudio doesn't use the FreeBSD config, I assume due to the disable of shm. I suggest a pkg-message to notify the user that the config is not fall-through (and why).

That's correct and I don't think this deserves any explanation. The config's
content itself makes it obvious why is it needed.

> libtracker-sparql has no src rpm listed in the distinfo

Fixed.

> nspr has no src rpm listed

Fixed.

> libglvnd has etc config dirs instead of a fall through to FreeBSD, on purpose or an oversight?

I have no idea, to be honest, but I fixed that.

> ca-certificates: the etc part needs to be fall through, having the stock CAs there in case the user has modified stuff in the corresponding FreeBSD side is security relevant.

I don't have /usr/local/etc/pki and I don't remember having it ever. FreeBSD
native nss package doesn't install this directory either. This port also
follows its c7 counterpart in this regard. So, I believe, this package should
not fallthrough.

> nss: don't know what the etc part specifies, but maybe likewise to the ca-certificates comment

Likewise, I don't think it should fallthrough.

> fontconfig: etc and var/db/fontconfig fall through is missing

It follows what c7 port does

> libusb: I'm surprised about
> ...

Fixed.

> openal-soft: no fall through. I'm on the edge here. A part of me agrees to no fall through, a part of me doesn't. Something like pulseaudio is sort of mainstream and may already be installed on the FreeBSD side (= fall through), openal doesn't look mainstream and a missing config may lead to a bad user experience.

Yes, I also not sure what to do in all these cases. All I know is that all this
stuff is arrange correctly enough to run such heavy applications as Linux
Chrome and R7 Office.

I'd leave it as it is for now until we bump into problems/bug reports.

> dbus-libs and some others: PORTREVISION is set, for some of them I see a correlation with the rpm name (some kind of package revision there too), but it is handled inconsistently and will diverge in case some port stuff needs to be fixed.

No, there is no correlation. We've been running these ports for a long time at
$WORK and decided to upstream this now. I spent a lot of time grooming the
history and squashing commits, so these PORTREVISIONs are the remnants of this
process that I missed. But they don't hurt anyways.

> linux-r19: the comment says it's centos

Fixed.

> vulkan: no fall through
> libvdpau: no fall through.

Didn't change that for the same reasons.

> r7-office + linux-chrome: I suggest to do a separate commit for this, not as part of the r19 introduction into the ports tree.

These are already separate commits in the pull request.

-- 
You are receiving this mail because:
You are the assignee for the bug.