This was previously reported in bug 691786 and bug 701032 and both were closed stating that the issue was fixed, but it's not. Instead, the change introduced to purportedly fix the issue introduced a new bug that obscured the original one: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/bind-9.16.12.ebuild?id=896faf4#n285 This is not valid Bash syntax: if [ ! -f '/etc/bind/rndc.key' && ! -f '/etc/bind/rndc.conf' ]; then The valid syntax is either: if [ ! -f '/etc/bind/rndc.key' -a ! -f '/etc/bind/rndc.conf' ]; then or: if [ ! -f '/etc/bind/rndc.key' ] && [ ! -f '/etc/bind/rndc.conf' ]; then However, the error is raised as non-fatal by Portage and it goes on finishing with a successful state: /var/tmp/portage/net-dns/bind-9.16.12/temp/environment: line 2807: [: missing `]' * * You can edit /etc/conf.d/named to customize named settings * * If you'd like to run bind in a chroot AND this is a new * install OR your bind doesn't already run in a chroot: * 1) Uncomment and set the CHROOT variable in /etc/conf.d/named. * 2) Run `emerge --config '=net-dns/bind-9.16.12'` * >>> Auto-cleaning packages... >>> No outdated packages were found on your system. But it won't generate rndc.key so named will fail to start: # sudo /etc/init.d/named start * Starting named ... * Checking named configuration ... /etc/bind/named.conf:90: option 'dnssec-enable' is obsolete and should be removed /etc/bind/named.conf:118: open: /etc/bind/rndc.key: file not found * named-checkconf failed! Please fix your config first. [ !! ] * ERROR: named failed to start After fixing this issue, the original error reported in bug 691786 and bug 701032 appears again if the urandom USE flag is enabled because this issue was never fixed: >>> Installing (1 of 1) net-dns/bind-9.16.12::gentoo * Using /dev/urandom for generating rndc.key rndc-confgen: The -r option has been deprecated. chown: cannot access '/etc/bind/rndc.key': No such file or directory * ERROR: net-dns/bind-9.16.12::gentoo failed (postinst phase): * (no error message) As already explained in the bugs mentioned and in the PR I submitted fixing this, the root cause of the issue is that on first installs where rndc.key doesn't exist, the ebuild calls rndc-confgen with the -r parameter if the urandom USE flag is enabled: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/bind-9.16.12.ebuild?id=896faf4#n288 But the -r parameter for rndc-confgen was removed three years ago: https://gitlab.isc.org/isc-projects/bind9/-/commit/3a4f820 So the use of -r parameter must be removed because it's no longer supported upstream and it causes an error on first installs when is urandom USE flag is enabled. Probably, the whole urandom flag and the creation of the random devices in the chroot environment at https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/bind-9.16.12.ebuild?id=896faf4#n367 can also be removed after the changes introduced in upstream commit 3a4f820, but I'm not so sure about this.
I pushed a new version of the PR I submitted fixing the original issue five months ago which was still pending review to also include a fix for the new syntax error: https://github.com/gentoo/gentoo/pull/18688
> Probably, the whole urandom flag and the creation of the random devices in the chroot environment at https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/bind-9.16.12.ebuild?id=896faf4#n367 can also be removed after the changes introduced in upstream commit 3a4f820, but I'm not so sure about this. I forgot I had already answered this point in my PR.
Sounds like confusion caused by usage of singles [ ] that's discouraged in ebuilds. bash-style [[ ... && ... ]] would be valid and what is normally used
That's true, changing the single brackets to double ones also fixes it, I just added that recommendation to my PR.
Should be fine now.
