savedconfig files within /etc/portage need to have "chmod a+r" permissions in order to be read with portage when emerging a package with saved config USE flag. If not, the ebuild will stop with little information pointing to a permissions problem. In essence, portage should: 1) Check permissions on /etc/portage and modify as needed? 2) Provide additional debug info concerning "permission denied" instead of just failing with "File not found" error -- See log below ("No saved config to restore" Reproducible: Always Actual Results: =sys-apps/portage-2.2_rc46 >>> Emerging (2 of 7) x11-wm/dwm-5.7.2 * dwm-5.7.2.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking dwm-5.7.2.tar.gz to /var/tmp/portage/x11-wm/dwm-5.7.2/work * Checking existence of //etc/portage/savedconfig/x11-wm/dwm-5.7.2 ... * Checking existence of //etc/portage/savedconfig/x11-wm/dwm-5.7.2 ... * Checking existence of //etc/portage/savedconfig/x11-wm/dwm ... * No saved config to restore - please remove USE=savedconfig or * provide a configuration file in //etc/portage/savedconfig/x11-wm/dwm * ERROR: x11-wm/dwm-5.7.2 failed: * config file needed when USE=savedconfig is specified * * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 1082: Called restore_config 'config.h' * environment, line 984: Called die * The specific snippet of code: * die "config file needed when USE=savedconfig is specified"; * * If you need support, post the output of 'emerge --info =x11-wm/dwm-5.7.2', * the complete build log and the output of 'emerge -pqv =x11-wm/dwm-5.7.2'. * The complete build log is located at '/var/tmp/portage/x11-wm/dwm-5.7.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-wm/dwm-5.7.2/temp/environment'. * S: '/var/tmp/portage/x11-wm/dwm-5.7.2/work/dwm-5.7.2' >>> Failed to emerge x11-wm/dwm-5.7.2, Log file:
It's alright to set whatever permissions you want on /etc/portage, and portage should only bail out or warn if absolutely necessary. In this case, it's savedconfig.eclass that's bailing out, and we might be able to improve the error message a little.
Think I"ve got things setup to where portage is using sandbox, or portage.portage (owner.group) permissions. As such, if portage encounters a "read only for owner" root, portage will bail with failing to read/access. So, either files should be set world readable if owned by root, or put them into group portage or as owner portage. (?) <shrugs> ... I've just be manually chmod'ing on an as need to basis.
http://sources.gentoo.org/eclass/savedconfig.eclass?r1=1.10&r2=1.11
(In reply to comment #3) '[[ -r ${base} ]]' probably should be changed to '[[ ! -r ${base} ]]'.
http://sources.gentoo.org/eclass/savedconfig.eclass?r1=1.11&r2=1.12
(lol @ error message...) ... blunt works for me, too.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3c88c805320021786d2bb925918e9ba2d15c79d commit c3c88c805320021786d2bb925918e9ba2d15c79d Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-09-26 23:47:13 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-09-29 19:32:44 +0000 savedconfig.eclass: drop faulty permissions check This check was meant to test if the user has accidentally restricted access to the /etc/portage/savedconfig directory. There are a few problems: 1. We don't actually need read access on the directory. We really need the execute bit set so that we can access files within the directory. 2. There may be permissions issues on subdirectories, and we would fail to detect them. 3. There is no easy way to distingish between EACCES and ENOENT using shell commands. We get an exit status of 1 from [[ -r ${path} ]] if there is a permissions problem or if some component of the path does not exist. This makes resolving problem 2 difficult without using a more robust language with direct access to errno. Instead of trying to detect a permissions problem, just output a warning telling the user to check permissions if we cannot find a config file. Bug: https://bugs.gentoo.org/289168 Bug: https://bugs.gentoo.org/814995 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/savedconfig.eclass | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
