PMS section 12.3.9 says about fowners and fperms: fowners Acts as for chown, but takes paths relative to the image directory. Failure behaviour is EAPI dependent as per section 12.3.1. fperms Acts as for chmod, but takes paths relative to the image directory. Failure behaviour is EAPI dependent as per section 12.3.1. However, when I try "fperms 700 usr/bin/foo", it miserably fails: >>> Install app-misc/foo-1 into /tmp/portage/app-misc/foo-1/image * Relative path passed to 'fperms': usr/bin/foo * This is unsupported. Please use 'chmod' when you need to work on files * outside the installation image (${ED}). chmod: cannot access 'usr/bin/foo': No such file or directory * ERROR: app-misc/foo-1::local failed (install phase): * fperms failed This is also inconsistent with other helpers like insinto or dostrip, which all accept pathnames relative to ${ED}.
To clarify: After printing the QA warning, these helpers continue, but interpret the pathname relative to the current working directory, which is not what the spec says.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=6fc4a7d45798f5ef6605419c684e0ddaa2e812ef commit 6fc4a7d45798f5ef6605419c684e0ddaa2e812ef Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2023-04-28 09:20:02 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-04-30 07:54:34 +0000 fowners, fperms: Fix handling of relative pathnames PMS section 12.3.9 specifies that fowners and fperms "[take] paths relative to the image directory." Currently, these helpers interpret any pathnames not beginning with a slash as relative to the current working directory (after printing a QA warning). This contradicts the spec. It is also inconsistent with other helpers like insinto or dostrip, which expand their pathnames relative to ${ED}. Bug: https://bugs.gentoo.org/905223 Closes: https://github.com/gentoo/portage/pull/1027 Signed-off-by: Ulrich Müller <ulm@gentoo.org> NEWS | 3 +++ bin/ebuild-helpers/fowners | 26 ++++++++++---------------- bin/ebuild-helpers/fperms | 25 ++++++++++--------------- 3 files changed, 23 insertions(+), 31 deletions(-)
AFAICS, the fix is included in Portage 3.0.48. Can this bug be closed?
Oops, yes, thanks!
