Bug 225378

Summary: devel/glib20: Fix mime search path when LOCALBASE != /usr/local (honour LOCALBASE)
Product: Ports & Packages Reporter: John Hein <jcfyecrayz>
Component: Individual Port(s)Assignee: freebsd-desktop (Team) <desktop>
Status: Closed FIXED    
Severity: Affects Some People CC: arrowd, desktop, gnome-ports-bugs, gnome, lwhsu, swills, tcberner, w.schwarzenfeld
Priority: --- Keywords: easy, needs-qa
Version: LatestFlags: koobs: merge-quarterly?
antoine: exp-run-
Hardware: Any   
OS: Any   
Attachments:
Description Flags
[patch] fix mime search patch for non-default LOCALBASE
none
[patch] v2: fix mime search patch for non-default LOCALBASE
koobs: maintainer-approval+
[patch] v3: fix mime search patch for non-default LOCALBASE
none
[patch] v4: fix mime search patch for non-default LOCALBASE tcberner: maintainer-approval+

Description John Hein 2018-01-22 13:19:43 UTC
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).
Comment 1 Walter Schwarzenfeld 2018-09-03 14:41:48 UTC
ping!
Comment 2 John Hein 2019-02-19 17:49:59 UTC
Created attachment 202168 [details]
[patch] v2: fix mime search patch for non-default LOCALBASE

Refresh patch against latest.
Comment 3 John Hein 2019-02-19 17:51:09 UTC
Maybe this should have an exp-run since it's so widely used?
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2019-02-20 12:34:53 UTC
Comment on attachment 202168 [details]
[patch] v2: fix mime search patch for non-default LOCALBASE

Approved by: portmgr (blanket: framework compliance, bugfix)

Pending QA
Comment 5 John Hein 2019-02-21 02:28:40 UTC
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
Comment 6 Tobias C. Berner freebsd_committer freebsd_triage 2020-11-05 05:04:09 UTC
Moin moin 

Is this still an issue?


mfg Tobias
Comment 7 Steve Wills freebsd_committer freebsd_triage 2021-01-06 06:04:41 UTC
(In reply to Tobias C. Berner from comment #6)
Yeah, I think so, I've seen issues when mime.cache isn't found.
Comment 8 John Hein 2021-01-29 13:02:49 UTC
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 9 Tobias C. Berner freebsd_committer freebsd_triage 2021-01-30 07:28:47 UTC
Comment on attachment 222005 [details]
[patch] v4: fix mime search patch for non-default LOCALBASE

Looks good to me.
Comment 10 commit-hook freebsd_committer freebsd_triage 2021-02-12 19:41:11 UTC
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
Comment 11 Tobias C. Berner freebsd_committer freebsd_triage 2021-02-12 19:41:19 UTC
Committed, thanks.
Comment 12 Gleb Popov freebsd_committer freebsd_triage 2023-10-21 17:16:35 UTC
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.
Comment 13 Jan Beich freebsd_committer freebsd_triage 2023-10-22 01:05:06 UTC
(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
Comment 14 Gleb Popov freebsd_committer freebsd_triage 2023-10-29 15:56:14 UTC
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