Message-ID: <bug-268540-4077-R4xbbfL8ZV@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-268540-4077@https.bugs.freebsd.org/bugzilla/> References: <bug-268540-4077@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268540 Alexander Leidinger <netchild@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |netchild@FreeBSD.org --- Comment #19 from Alexander Leidinger <netchild@FreeBSD.org> --- I'm not tijl, but I'm the one who wrote (years ago) the base of the linux userland stuff which we have today (which has a lot of good improvements si= nce then). What I looked at: - the Mk files - if source rpms are in the distinfo - if config files are "fall through to FreeBSD config where possible" What I noticed: - 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). - libtracker-sparql has no src rpm listed in the distinfo - nspr has no src rpm listed - libglvnd has etc config dirs instead of a fall through to FreeBSD, on purpose or an oversight? - 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. - nss: don't know what the etc part specifies, but maybe likewise to the ca-certificates comment - fontconfig: etc and var/db/fontconfig fall through is missing - libusb: I'm surprised about .if ${ARCH} =3D=3D amd64 && ${FLAVOR:Mc7} ONLY_FOR_ARCHS+=3D i386 I would have expected a +=3Di386 in the c7 case alone. Am I misunderstan= ding something that this doesn't make sense to me? - 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 (=3D fall throu= gh), openal doesn't look mainstream and a missing config may lead to a bad user experience. - 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), bu= t it is handled inconsistently and will diverge in case some port stuff needs to= be fixed. If this is for your local install and it will go away on a version increment: ignore this comment. - linux-r19: the comment says it's centos - vulkan: no fall through - libvdpau: no fall through. - r7-office + linux-chrome: I suggest to do a separate commit for this, no= t as part of the r19 introduction into the ports tree. Generic note: we don't install the corresponding FreeBSD port if we have a config fall through. This only matters if the actual software is used inste= ad of simply part of the linux base. Personally I didn't care much about this case, when I needed something I simply installed it, but maybe we want to rethink what we do here (I do not consider this in-scope of this PR, I simp= ly mention it for completeness). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268540-4077-R4xbbfL8ZV>