https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268540
--- Comment #21 from Gleb Popov <arr...@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.
