A weird experience today. Look at this: at first normal behavior: --- # emerge -1 gentoolkit These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild R ] app-portage/gentoolkit-0.4.0::gentoo PYTHON_TARGETS="-pypy python2_7 -python3_4 python3_5 -python3_6" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB --- Today I can restrict gentoolkit to stable release and I change my /etc/portage/package.accept_keywords: --- app-portage/gentoolkit -~amd64 ---- Now portage considers th python USE and thinks we don't want an unstable python-3.5 --- # emerge -1 gentoolkit These are the packages that would be merged, in order: Calculating dependencies .. ....... done! [ebuild R ] app-portage/gentoolkit-0.4.0::gentoo PYTHON_TARGETS="(-pypy) python2_7 -python3_4 (-python3_5*) (-python3_6)" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] --- I am pretty sure this is a new behavior of portages artificial intelligence?
A similar behavior of portage is affecting the USE of libressl. Changing the release directives of --- dev-libs/libevent -~amd64 dev-libs/xmlsec -~amd64 net-wireless/crda -~amd64 net-misc/wget -~amd64 --- in /etc/portage/package.accept_keywords will provoke a USE openssl on my Gentoo USE libressl --- # emerge -1 dev-libs/libevent dev-libs/xmlsec net-misc/wget net-wireless/crda dev-libs/libressl These are the packages that would be merged, in order: Calculating dependencies ......... done! [ebuild R ] dev-libs/libressl-2.6.0:0/43::gentoo USE="asm -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild N ] dev-libs/openssl-1.0.2l::gentoo USE="asm -bindist gmp -kerberos -rfc3779 -sctp -sslv2 sslv3 -static-libs {-test} -tls-heartbeat -vanilla zlib" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="(sse2)" 5.240 KiB [ebuild R ] dev-libs/libevent-2.1.8:0/2.1-6::gentoo USE="-debug (-libressl*) ssl -static-libs {-test} threads" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild R ] dev-libs/xmlsec-1.2.24-r1::gentoo USE="-doc gcrypt gnutls (-libressl*) nss -openssl -static-libs" 0 KiB [ebuild R ] net-wireless/crda-3.18-r1::gentoo USE="-gcrypt (-libressl*)" 61 KiB [ebuild R ] net-misc/wget-1.19.1-r1::gentoo USE="-debug -gnutls idn ipv6 (-libressl*) nls -ntlm pcre ssl -static {-test} uuid zlib" 0 KiB [blocks B ] dev-libs/openssl:0 ("dev-libs/openssl:0" is blocking dev-libs/libressl-2.6.0) Total: 6 packages (1 new, 5 reinstalls), Size of downloads: 5.300 KiB Conflict: 1 block (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (dev-libs/openssl-1.0.2l:0/0::gentoo, ebuild scheduled for merge) pulled in by dev-libs/openssl:0= required by (net-misc/wget-1.19.1-r1:0/0::gentoo, ebuild scheduled for merge) dev-libs/openssl:0 required by (net-wireless/crda-3.18-r1:0/0::gentoo, ebuild scheduled for merge) >=dev-libs/openssl-1.0.1h-r2:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (>=dev-libs/openssl-1.0.1h-r2:0[abi_x86_32(-),abi_x86_64(-)]) required by (dev-libs/libevent-2.1.8:0/2.1-6::gentoo, ebuild scheduled for merge) (dev-libs/libressl-2.6.0:0/43::gentoo, ebuild scheduled for merge) pulled in by .... many lines output .... --- That means I cannot use management of wanted version with release directives in /etc/portage/package.accept_keywords any more.
(In reply to Ulenrich from comment #1) > That means I cannot use management of wanted version > with release directives in /etc/portage/package.accept_keywords > any more. I believe you are now just expected to override these lines in your /etc/portage/profile/use.stable.mask instead: /usr/portage/profiles/base/use.stable.mask:29:python_targets_python3_5 /usr/portage/profiles/base/use.stable.mask:30:python_single_target_python3_5 /usr/portage/profiles/base/use.stable.mask:36:curl_ssl_libressl /usr/portage/profiles/base/use.stable.mask:37:libressl Personally, putting stable packages in /etc/portage/package.accept_keywords has always felt more like a workaround than a solution to me.
(In reply to Jouni Kosonen from comment #2) > (In reply to Ulenrich from comment #1) > > That means I cannot use management of wanted version > > with release directives in /etc/portage/package.accept_keywords > > any more. > > I believe you are now just expected to override these lines in your > /etc/portage/profile/use.stable.mask instead: > > /usr/portage/profiles/base/use.stable.mask:29:python_targets_python3_5 > /usr/portage/profiles/base/use.stable.mask:30:python_single_target_python3_5 > /usr/portage/profiles/base/use.stable.mask:36:curl_ssl_libressl > /usr/portage/profiles/base/use.stable.mask:37:libressl Right, I would put some settings like this in /etc/portage/profile/use.mask: -python_targets_python3_5 -python_single_target_python3_5 python_single_target_python3_4
OK, I got it, I have to look into use.stable.mask libressl mask at profiles/base/use.stable.mask --- # Justin Lecher <jlec@gentoo.org> (30 Sep 2015) # No stable libressl yet # Addendum: also mask the USE_EXPAND flag, # Anthony G. Basile <blueness@gentoo.org> (26 Nov 2015) curl_ssl_libressl libressl --- should be unset for amd64 at profiles/default/linux/amd64 as there is now a stable =dev-libs/libressl-2.6.0 Or is it hold back because of X86 not yet stable regarding multilib ?
(In reply to Ulenrich from comment #4) > OK, I got it, I have to look into use.stable.mask > > libressl mask at profiles/base/use.stable.mask > --- > # Justin Lecher <jlec@gentoo.org> (30 Sep 2015) > # No stable libressl yet > # Addendum: also mask the USE_EXPAND flag, > # Anthony G. Basile <blueness@gentoo.org> (26 Nov 2015) > curl_ssl_libressl > libressl Probably the profiles just need to to be updated, since libressl was only recently marked stable, see bug 627696. You'll probably want something like this in /etc/portage/profile/use.mask until bug 627696 is closed (bug CC list shows it's currently waiting on arm and x86): -curl_ssl_libressl -libressl
Thanks to @Zac and @Jouni I thought I had found an error of portage but it was a kompetence issue of mine again after all my years using Gentoo :( Excuse me!
