Created attachment 189964 [details] [patch] fix mime search patch for non-default LOCALBASE glib fails to find mime.cache when LOCALBASE is not /usr/local. Workaround: define XDG_DATA_DIRS in environment. Fix: see attached patch Bump PORTREVISION at your discretion. This will only change the package for those who have a non-default LOCALBASE (i.e., not official freebsd packages).
ping!
Created attachment 202168 [details] [patch] v2: fix mime search patch for non-default LOCALBASE Refresh patch against latest.
Maybe this should have an exp-run since it's so widely used?
Comment on attachment 202168 [details] [patch] v2: fix mime search patch for non-default LOCALBASE Approved by: portmgr (blanket: framework compliance, bugfix) Pending QA
Created attachment 202212 [details] [patch] v3: fix mime search patch for non-default LOCALBASE (In reply to Kubilay Kocak from comment #4) v3: I refreshed the patch files via makepatch for the patch files I touched (no unnecessary churn for untouched patch files). QA: poudriere testport: ok portlint: ok, no new warnings
Moin moin Is this still an issue? mfg Tobias
(In reply to Tobias C. Berner from comment #6) Yeah, I think so, I've seen issues when mime.cache isn't found.
Created attachment 222005 [details] [patch] v4: fix mime search patch for non-default LOCALBASE (In reply to Tobias C. Berner from comment #6) Yes, this is definitely still needed. The same issue with non-default LOCALBASE still exists. The port has been updated a few times, but the pieces affected in the files in this patch have not changed much. This v4 patch is just a refresh against the latest version of the port. The change is really quite straightforward. Bump PORTREVISION at committer's discretion - no change for default LOCALBASE.
Comment on attachment 222005 [details] [patch] v4: fix mime search patch for non-default LOCALBASE Looks good to me.
A commit references this bug: Author: tcberner Date: Fri Feb 12 19:40:21 UTC 2021 New revision: 565056 URL: https://svnweb.freebsd.org/changeset/ports/565056 Log: devel/glib20: Fix mime search path when LOCALBASE != /usr/local (honour LOCALBASE) - explicitely not bumping port revision, as the package does not change for people who are using the defaults LOCALBASE=/usr/local -- no need to burden the package builders for this. PR: 225378 Submitted by: John Hein <jcfyecrayz@liamekaens.com> Changes: head/devel/glib20/Makefile head/devel/glib20/files/patch-gio_xdgmime_xdgmime.c head/devel/glib20/files/patch-glib_gutils.c head/devel/glib20/files/patch-glib_tests_utils.c
Committed, thanks.
I'd argue that these patches are actually wrong. The standard states [1] that, for instance, XDG_DATA_DIRS defaults to "/usr/local/share:/usr/share". If you have unusual value for LOCALBASE then you're expected to somehow set XDG_DATA_DIRS environment variable globally rather than patching the code implementing the spec. [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html , the "Environment variables" chapter.
(In reply to Gleb Popov from comment #12) I disagree. Patching is correct but suboptimal. /usr/local in XDG is based on Linux FHS aka GNU hier(7). /usr/local should *not* be modified by system package manager. NetBSD made PkgSrc compatible by changing LOCALBASE default while FreeBSD takes advantage of ambiguity/mess under POLA banner. FreeBSD hier(7) cannot guarantee /usr/local exists outside of ports(7) context. Nowadays, /usr/local is semi-standardized (used by base system but not documented in hier(7) yet) as LOCABLASE environment variable with "sysctl user.localbase" fallback. FreeBSD equivalent of /usr/local in GNU hier(7) would be any custom non-conflicting top-level directory like /local. Given FreeBSD already uses "local" to denote site-local configuration (e.g., rc.conf vs. rc.conf.local) top-level /local can be a natural extension even if not defined by hier(7). See also https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html https://github.com/netbsd/pkgsrc/commit/41ed126f8745 https://wiki.freebsd.org/WarnerLosh/UsrLocal
It took me multiple attempts to read and understand all of this. Yes, or /usr/local is indeed a different thing from Linux' understanding. From what I gather, it turns out that you're right on this matter. Not that I wanted to remove these patches, but I had a related discussion with an AppStream developer [1], so I wanted to clear this up. Thanks for the insights! [1] https://github.com/ximion/appstream-generator/pull/113#issuecomment-1527037485