Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 626058

Summary: sys-apps/portage: emerge unexpectedly tries to autounmask =dev-db/postgresql-10_beta2, and --autounmask-keep-masks suppresses the problem
Product: Portage Development Reporter: Mark Wagner <mark>
Component: Core - DependenciesAssignee: Portage team <dev-portage>
Status: CONFIRMED ---    
Severity: normal CC: esigra, mark, pacho
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 376695    

Description Mark Wagner 2017-07-24 17:20:38 UTC
I have "postgres" in my USE and dev-db/postgresql:10 in my /etc/portage/package.mask. When I attempt to run

emerge -u --deep --newuse --with-bdeps y --keep-going world

I get this error:

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by dev-libs/cyrus-sasl-2.1.26-r11::gentoo[postgres]
# required by mail-mta/sendmail-8.14.9-r1::gentoo[sasl]
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.

The cyrus-sasl-2.1.26-r11 ebuild has "postgres? ( dev-db/postgresql:= )" in its DEPEND. From

:= means that any slot is acceptable, and that your package should be rebuilt if the version best matching the runtime dependency is updated to a version with a different slot or subslot;

From this I conclude postgresql:9 should be acceptable and masking postgresql:10 should not cause an error.

This is not specific to cyrus-sasl-2.1.26-r11. If I remove postgres from cyrus-sasl I get the same error with dev-libs/apr-util.
Comment 1 Mark Wagner 2017-07-24 17:22:03 UTC
There is some discussion in
Comment 2 Mark Wagner 2017-07-24 17:23:04 UTC
 I am running sys-apps/portage-2.3.6. There was no 2.3 option in the version dropdown.
Comment 3 Zac Medico gentoo-dev 2017-07-24 18:20:40 UTC
Does it work any better with the --autounmask-keep-masks=y option?
Comment 4 Mark Wagner 2017-07-24 19:47:35 UTC
To complete my world update I unmasked postgresql:10. To test you suggestion I unmerged it and masked it. --autounmask-keep-masks solves the problem:

emerge -upv --deep --newuse --with-bdeps y --keep-going --autounmask --autounmask-keep-masks world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] dev-db/postgresql-9.6.3-r2:9.6::gentoo [9.6.3-r1:9.6::gentoo] USE="nls pam perl readline server ssl threads xml zlib -doc -kerberos -ldap -libressl -pg_legacytimestamp -python (-selinux) -static-libs -systemd -tcl -uuid" LINGUAS="en -af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW" PYTHON_SINGLE_TARGET="python2_7 -python3_4 -python3_5 -python3_6" PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" 19077 KiB
[ebuild  rR    ] dev-libs/apr-util-1.6.0:1::gentoo  USE="berkdb gdbm mysql postgres sqlite -doc -ldap -libressl -nss -odbc -openssl -static-libs" 419 KiB
[ebuild  rR    ] dev-libs/cyrus-sasl-2.1.26-r11:2::gentoo  USE="gdbm mysql pam postgres sample sqlite ssl -authdaemond -berkdb -java -kerberos -ldapdb -libressl -openldap (-selinux) -srp -static-libs -urandom" ABI_X86="(64) -32 (-x32)" 5098 KiB

Total: 3 packages (1 upgrade, 2 reinstalls), Size of downloads: 24594 KiB

Thanks for the suggestion.
Comment 5 Aaron W. Swenson gentoo-dev 2017-12-22 14:04:56 UTC
I just run into this problem myself on my prod server at work, but not with PostgreSQL.

Anything that had a Python dependency wanted me to unmask/keyword some other package despite the dependency declaration lacking any version preference (e.g.,  DEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"). Continuing with this example, Portage wanted me to keyword the highest version in the repo despite setuptools-34 satisfying the DEPEND just fine.

I've resolved this by adding the following to /etc/portage/make.conf:

     PYTHON_TARGETS="python2_7 python3_4"

I've even added python3_5 without needing to unmask/keyword any packages.

Removing python3_4 and leaving python{2_7,3_5} caused portage to demand unmasking/keywording packages.