From nobody Fri Jan 27 13:12:19 2023 X-Original-To: desktop@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P3Hzl248Zz3bvS4 for ; Fri, 27 Jan 2023 13:12:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P3Hzk6R9qz4KZj for ; Fri, 27 Jan 2023 13:12:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674825138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4WvD3ROdVr5EIqMbZF/6PrfDHTkkoOc7VZotkBkq7os=; b=f4eooxB7aTYkjgOB1i98JrYVhTs/V5mwJhBaFBvqbeMSOWnO36GjuXF4SJlU497BJPDTOe cO6JP+tP+Bp/RvijU6t+kwowzMpjPjMBOMe3cm4Pc9Mf3iCZmB7ZhZXdYujgS+NHFfk4kb iOFgmswkcABlzWmClkXdsr2e/8yICdPVWCfmypF7MvQ6SqWLS9KXz7vt1pmoh6dvueKw6l /tL0ODGUOv0gwLYp3yUrhu+wK7/gnRSvsSsi1G2O69Xso9MMWzQzGY0qHgiQSxcc2p4lQU zo/qQDPnyaSRgHhVqsmCMy9FZQlrXCDMp4jL0Gd1Qp8NN5mLeWvdbiRLnzgFdw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674825138; a=rsa-sha256; cv=none; b=MXQd+Dmb9nIoZgmgSY3CDBDxVN6zKQsy2zq9UjOImvZBSu1RtN3iV4K0lkhK3C5bneGwws Pblb09pNJnSxK/lLwU9JkqP7ZQfM9Yp7NeMoz1GQ4W5LcJ/z9M1NLK/BxI5nTuAtztcZD3 dDsEUAO3u8hmeyuQOMsz+jLd2AZRXZAg6A6LiyJFwnxMq/FcyHI32GRhWnBhzLWMet8Cvv j7CDzO3SIrDEoQvz+/iTGgRAcMFeUSABzh84O+xDDV60Zk9/3Ye5quRui6sj2OYZ4py5Bf +essio8msMNm7NuBoAGDyfQuyPTRp6TSER1vKPtuvG6Yf98OaGdzVUFa1wgpyQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4P3Hzk5XhBz18mJ for ; Fri, 27 Jan 2023 13:12:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 30RDCIpk055835 for ; Fri, 27 Jan 2023 13:12:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30RDCIlH055834 for desktop@FreeBSD.org; Fri, 27 Jan 2023 13:12:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: [Bug 258372] x11-fonts/fontconfig: cannot install as user (into non-default prefix) Date: Fri, 27 Jan 2023 13:12:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jcfyecrayz@liamekaens.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: desktop@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Using and improving FreeBSD on the desktop List-Archive: https://lists.freebsd.org/archives/freebsd-desktop List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-desktop@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258372 --- Comment #6 from John Hein --- (In reply to Gerald Pfeifer from comment #4) > Does /var/db/fontconfig exist on your system? If so, that might explain > why it does not try to generate that directory, whereas it does it in my > case - and fails. Yes, /var/db/fontconfig did exist in my previous testing. When I move it a= way and re-install ('make -C x11-fonts/fontconfig INSTALL_AS_USER=3D1 LOCALBASE=3D/usr/local.user PKG_DBDIR=3D/usr/local.user/var/db/pkg PORT_DBDIR=3D/usr/local.user/var/db/ports reinstall'), it fails with 'pkg: = Fail to create /var/db/fontconfig:Permission denied' as described in comment 0. So the pkg-create(8) man page where @dir is described is incomplete (IMO). = It only discusses what happens when the pkg is deleted. It omits any descript= ion about behavior on pkg install. One could read that the implication of that omission is that nothing is done at install. But that does not appear to b= e a correct interpretation of that omission. To be more clear, the pkg-create(= 8) man page could describe @dir behavior at install time. So, given confirmation of that error, what should fontconfig (or other ports per comment 1) do for @dir entries that point explicitly to directories whe= re the user does not have write permission when INSTALL_AS_USER is set? Some possible courses of action: (1) Change the pkg tool. pkg could warn instead of fail for @dir creation= (or deletion?) failures if INSTALL_AS_USER is set. pkg already looks for INSTALL_AS_USER to: o Skip chflags o Skip chown o Skip checks that fail if the pkg db file is not owned by root. Perhaps that check is not needed, or should not trigger an exit at the point of the check anyway. The pkg tool will not be able to write to the db file if the user does not have the appropriate permissions, so just let pkg fail natura= lly when it does the write attempt. The check could remain and just emit a war= ning (instead of being fatal if the check fails) regardless of INSTALL_AS_USER. (2) Modify plist for INSTALL_AS_USER. Ports that have @dir entries that point to non-user directories, could have a plist that sets a different val= ue for the @dir directory. Maybe /var/db/fontconfig in this case, = for instance. What defines a "non-user" directory is not obvious, however - anything outside PREFIX? anything outside LOCALBASE? Maybe there could be = an INSTALL_AS_USER_ROOT variable where such plist entries would go (instead of= the default /) when using INSTALL_AS_USER. (3) A variant of (2)... allow currently hard-coded directories in the pli= st like /var/db/fontconfig to be defined by a make variable (instead of hard-coded). For example, have the plist entry be something like @dir %%FONTCONFIG_DB%% and define FONTCONFIG_DB in PLIST_SUB. This would defaul= t to /var/db/fontconfig, of course - and maybe it could default to ${LOCALBASE}/var/db/fontconfig if INSTALL_AS_USER is set. (4) Continue with existing behavior (but document it). If INSTALL_AS_USE= R is set, expect that @dir directories are in a parent directory that is expecte= d to be writable by the install user. This is effectively what is done now. But that policy is likely just an implicit or even just accidental policy - it could be explicitly spelled out in the @dir documentation. (2) and (3) would be per-port modifications (as opposed to a change to the ports framework or the pkg tool). There could be another variant of (2) or= (3) that could be defined by the framework so individual ports affected by this issue would not need to be modified one by one. For instance, when a hard-coded absolute path is an argument to @dir (or maybe an absolute path = that is outside of PREFIX / LOCALBASE?), the plist generation step in bsd.port.mk could be modified to change the @dir entry to, say, '@dir /dir' = when INSTALL_AS_USER is set. Or the pkg tool could be modified to do something similar (I don't like that as well, however - pkg should just do what the p= list says to do, so the plist should be modified as needed before being passed to pkg). If we don't want to define a global policy for @dir when INSTALL_AS_USER is= set (i.e., modify the framework or pkg tool for these cases), I think I prefer = (3) for each affected port at this time. If we do want to implement something that does not requiring changes for ev= ery affected port, I think I prefer (2) - specifically modifying generate-plist= in bsd.port.mk to detect absolute path @dir entries that are outside PREFIX or LOCALBASE and prepend ${INSTALL_AS_USER_ROOT} (any potential better name suggestion for that is welcome). --=20 You are receiving this mail because: You are the assignee for the bug.=