Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 452898 - Portage only does dependency checking on the latest slot
Summary: Portage only does dependency checking on the latest slot
Status: RESOLVED OBSOLETE
Alias: None
Product: Documentation
Classification: Unclassified
Component: Devmanual (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo Devmanual Team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2013-01-19 05:47 UTC by Matthew Schultz
Modified: 2020-02-28 11:13 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
slot_dependency_targets.patch (slot_dependency_targets.patch,1014 bytes, patch)
2013-01-19 06:09 UTC, Matthew Schultz
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Schultz 2013-01-19 05:47:21 UTC
Portage only does dependency checking on the latest slot. So if one package requires another package to be changed by a use flag, then only the latest slot is targeted for recompilation instead of all installed slots.  This should be documented in the devmanual under slot dependencies.

Reproducible: Always
Comment 1 Matthew Schultz 2013-01-19 06:09:16 UTC
Created attachment 336090 [details, diff]
slot_dependency_targets.patch

Patch to explain how to deal with targeted slots.  Comments are welcome.
Comment 2 Markos Chandras (RETIRED) gentoo-dev 2013-01-19 10:14:21 UTC
Hmm, is this a desired behavior of portage? Adding a dep for each slot does not look right to me. I would expect portage to be smart to rebuild all installed slots. No? CC'ing pms
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-19 10:18:49 UTC
(In reply to comment #2)
> Hmm, is this a desired behavior of portage? Adding a dep for each slot does
> not look right to me. I would expect portage to be smart to rebuild all
> installed slots. No? CC'ing pms

Yes, it is desired and 100% correct. If you dep on a package without specifying version, you dep on the latest version. Older slots don't matter.

For the case considered here, I think the *only* semi-reasonable solution right now is to block all slots of php without USE=ssl. Other solutions involve either requesting at least one slot with USE=ssl, or always installing all slots of php.
Comment 4 Matthew Schultz 2013-01-21 13:58:50 UTC
(In reply to comment #3)
> For the case considered here, I think the *only* semi-reasonable solution
> right now is to block all slots of php without USE=ssl. 

Could you clarify with an example?

>Other solutions involve either requesting at least one slot with USE=ssl, 

Isn't this what it already does but just with the latest slot?

> or always installing all slots of php.

I thought it made more sense to only build/rebuild "targeted" slots since that's only what is needed to satisfy the dependency properly and you're not doing more compiling than necessary.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-21 14:10:17 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > For the case considered here, I think the *only* semi-reasonable solution
> > right now is to block all slots of php without USE=ssl. 
> 
> Could you clarify with an example?

RDEPEND="dev-lang/php[ssl]
  !dev-lang/php:5.3[-ssl]
  !dev-lang/php:5.4[-ssl]
  !dev-lang/php:5.5[-ssl]
"

Explanation:

1. Request *at least one* (any) php version with SSL enabled,

2. Disallow having SSL disabled on any of the php versions if they are installed.

> >Other solutions involve either requesting at least one slot with USE=ssl, 
> 
> Isn't this what it already does but just with the latest slot?

Yes and no. The dependency says 'any slot with USE=ssl'. What gets pulled actually depends much on the design and options.

In other words, if you don't request updating php and have older version (slot) installed with the flag enabled, it will suffice the dependency.

> > or always installing all slots of php.
> 
> I thought it made more sense to only build/rebuild "targeted" slots since
> that's only what is needed to satisfy the dependency properly and you're not
> doing more compiling than necessary.

And how do you know which are 'targeted'?
Comment 6 Matthew Schultz 2013-01-21 14:19:15 UTC
(In reply to comment #5)
> > Could you clarify with an example?
> 
> RDEPEND="dev-lang/php[ssl]
>   !dev-lang/php:5.3[-ssl]
>   !dev-lang/php:5.4[-ssl]
>   !dev-lang/php:5.5[-ssl]
> "
> 
> Explanation:
> 
> 1. Request *at least one* (any) php version with SSL enabled,
> 
> 2. Disallow having SSL disabled on any of the php versions if they are
> installed.

I like this method because it would work with any slotted package and not just php as my documented method.   I'll submit a new patch to devmanual with this method.

> 
> > >Other solutions involve either requesting at least one slot with USE=ssl, 
> > 
> > Isn't this what it already does but just with the latest slot?
> 
> Yes and no. The dependency says 'any slot with USE=ssl'. What gets pulled
> actually depends much on the design and options.
> 
> In other words, if you don't request updating php and have older version
> (slot) installed with the flag enabled, it will suffice the dependency.

This seems more reasonable than automatically assuming an upgrade is necessary.

> And how do you know which are 'targeted'?

As stated above, my solution works for php because there are targets (php_targets_5-3, php_targets_5-4, etc) in the eclass but that wouldn't work for all slotted packages.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-21 14:27:51 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > > Could you clarify with an example?
> > 
> > RDEPEND="dev-lang/php[ssl]
> >   !dev-lang/php:5.3[-ssl]
> >   !dev-lang/php:5.4[-ssl]
> >   !dev-lang/php:5.5[-ssl]
> > "
> > 
> > Explanation:
> > 
> > 1. Request *at least one* (any) php version with SSL enabled,
> > 
> > 2. Disallow having SSL disabled on any of the php versions if they are
> > installed.
> 
> I like this method because it would work with any slotted package and not
> just php as my documented method.   I'll submit a new patch to devmanual
> with this method.

And I don't like it because random dependencies are not the place to ensure that.

Especially, that a particular user may not need to have USE=ssl enabled on the php versions he won't use your package with. You are making a lot of work which would be meaningless for the majority, painful for a minority and will help a few users which do stupid things.
Comment 8 Matthew Schultz 2013-01-21 15:13:55 UTC
(In reply to comment #7)
> And I don't like it because random dependencies are not the place to ensure
> that.

Where is the proper place to ensure that?  Is there the possibility then that portage will be changed to accommodate for this?


> Especially, that a particular user may not need to have USE=ssl enabled on
> the php versions he won't use your package with. You are making a lot of
> work which would be meaningless for the majority, painful for a minority and
> will help a few users which do stupid things.

I'm not sure how this would be a stupid thing.  This is about what the user has his php targets set to.  If the user is targeting both installed versions, then he wants the dependency on the package he is emerging to apply to both versions.

If you have two different versions of php installed and you have the ssl use flag on php disabled or not set, then you attempt to emerge a package (e.g. pecl extension) where you have the php targets set for both of the php versions you have installed, it will stop and prompt you to change the ssl use flag on the latest installed version of php installed.  So you enable the ssl use flag on php (not just the latest slotted version), the dependency is satisfied and the package emerges but the problem is the old version of php was not reemerged with the ssl use flag even though you have that version targeted for support.

Example:

1. php 5.3 and 5.4 are installed with USE="-ssl":

emerge -pv php:5.3 php:5.4

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

Calculating dependencies... done!
[ebuild   R   ~] dev-lang/php-5.4.10:5.4  USE="apache2 bcmath bzip2 calendar cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar posix readline session simplexml snmp soap sockets spell sqlite ssl* sysvipc threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib -berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm (-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl -libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode (-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc" 0 kB
[ebuild   R   ~] dev-lang/php-5.3.20:5.3::x-portage  USE="apache2 bcmath bzip2 calendar cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar posix readline session simplexml snmp soap sockets spell sqlite sqlite2 ssl* sysvipc threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib -berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm (-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl -libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode (-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc" 0 kB


2. USE="-ssl" emerge pecl-oauth (pecl-oauth is just an example at this point since the version in portage doesn't depend on ssl use flag yet but my ebuild has dev-lang/php[ssl] in DEPEND)

emerge pecl-oauth
Calculating dependencies... done!
[ebuild   R   ~] dev-lang/php-5.4.10  USE="ssl*" 
[ebuild  N    ~] dev-php/pecl-oauth-1.2.3  USE="curl -ssl" PHP_TARGETS="php5-3 php5-4" 

The following USE changes are necessary to proceed:
#required by dev-php/pecl-oauth-1.2.3, required by pecl-oauth (argument)
>=dev-lang/php-5.4.10:5.4 ssl


3. Then I change the ssl use flag so it is enabled for what I think is all versions of php instead of what portage is telling me here in my package.use file:

dev-lang/php ssl


4. emerge -pv pecl-oauth

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

Calculating dependencies... done!
[ebuild   R   ~] dev-lang/php-5.4.10:5.4  USE="apache2 bcmath bzip2 calendar cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar posix readline session simplexml snmp soap sockets spell sqlite ssl* sysvipc threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib -berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm (-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl -libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode (-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc" 0 kB
[ebuild  N    ~] dev-php/pecl-oauth-1.2.3::x-portage  USE="curl ssl" PHP_TARGETS="php5-3 php5-4" 0 kB

5. So then only php 5.4 is reemerged but pecl-oauth is compiling for both versions of php.  Since php 5.3 isn't recompiled, this will cause pecl-oauth to disable the ssl support potentially or just outright die on the user with an ebuild error even though that's not what should be happening.
Comment 9 Matthew Schultz 2013-01-21 15:19:26 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > And I don't like it because random dependencies are not the place to ensure
> > that.
> 
> Where is the proper place to ensure that?  Is there the possibility then
> that portage will be changed to accommodate for this?
> 
> 
> > Especially, that a particular user may not need to have USE=ssl enabled on
> > the php versions he won't use your package with. You are making a lot of
> > work which would be meaningless for the majority, painful for a minority and
> > will help a few users which do stupid things.
> 
> I'm not sure how this would be a stupid thing.  This is about what the user
> has his php targets set to.  If the user is targeting both installed
> versions, then he wants the dependency on the package he is emerging to
> apply to both versions.
> 
> If you have two different versions of php installed and you have the ssl use
> flag on php disabled or not set, then you attempt to emerge a package (e.g.
> pecl extension) where you have the php targets set for both of the php
> versions you have installed, it will stop and prompt you to change the ssl
> use flag on the latest installed version of php installed.  So you enable
> the ssl use flag on php (not just the latest slotted version), the
> dependency is satisfied and the package emerges but the problem is the old
> version of php was not reemerged with the ssl use flag even though you have
> that version targeted for support.
> 
> Example:
> 
> 1. php 5.3 and 5.4 are installed with USE="-ssl":
> 
> emerge -pv php:5.3 php:5.4
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ~] dev-lang/php-5.4.10:5.4  USE="apache2 bcmath bzip2 calendar
> cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp
> hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar
> posix readline session simplexml snmp soap sockets spell sqlite ssl* sysvipc
> threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib
> -berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm
> (-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl
> -libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode
> (-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc" 0 kB
> [ebuild   R   ~] dev-lang/php-5.3.20:5.3::x-portage  USE="apache2 bcmath
> bzip2 calendar cjk cli crypt ctype curl curlwrappers exif fileinfo filter
> ftp gd gdbm gmp hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls
> pcntl pdo phar posix readline session simplexml snmp soap sockets spell
> sqlite sqlite2 ssl* sysvipc threads tidy tokenizer truetype unicode wddx xml
> xmlwriter xpm xsl zip zlib -berkdb -cdb -cgi -debug -doc -embed -enchant
> -firebird -flatfile -fpm (-frontbase) -imap -inifile -intl -iodbc -kerberos
> (-kolab) -ldap-sasl -libedit -mssql -oci8-instant-client -odbc -pic
> -postgres -qdbm -recode (-selinux) -sharedmem (-sybase-ct) -xmlreader
> -xmlrpc" 0 kB
> 
> 
> 2. USE="-ssl" emerge pecl-oauth (pecl-oauth is just an example at this point
> since the version in portage doesn't depend on ssl use flag yet but my
> ebuild has dev-lang/php[ssl] in DEPEND)
> 
> emerge pecl-oauth
> Calculating dependencies... done!
> [ebuild   R   ~] dev-lang/php-5.4.10  USE="ssl*" 
> [ebuild  N    ~] dev-php/pecl-oauth-1.2.3  USE="curl -ssl"
> PHP_TARGETS="php5-3 php5-4" 
> 
> The following USE changes are necessary to proceed:
> #required by dev-php/pecl-oauth-1.2.3, required by pecl-oauth (argument)
> >=dev-lang/php-5.4.10:5.4 ssl
> 
> 
> 3. Then I change the ssl use flag so it is enabled for what I think is all
> versions of php instead of what portage is telling me here in my package.use
> file:
> 
> dev-lang/php ssl
> 
> 
> 4. emerge -pv pecl-oauth
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ~] dev-lang/php-5.4.10:5.4  USE="apache2 bcmath bzip2 calendar
> cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp
> hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar
> posix readline session simplexml snmp soap sockets spell sqlite ssl* sysvipc
> threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib
> -berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm
> (-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl
> -libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode
> (-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc" 0 kB
> [ebuild  N    ~] dev-php/pecl-oauth-1.2.3::x-portage  USE="curl ssl"
> PHP_TARGETS="php5-3 php5-4" 0 kB
> 
> 5. So then only php 5.4 is reemerged but pecl-oauth is compiling for both
> versions of php.  Since php 5.3 isn't recompiled, this will cause pecl-oauth
> to disable the ssl support potentially or just outright die on the user with
> an ebuild error even though that's not what should be happening.

Disregard the ssl use flag in my pecl-oauth example.  Technically it's optional but I removed the optional use flag part in DEPEND to make it required to prove my point.
Comment 10 Matthew Schultz 2013-01-21 15:46:28 UTC
(In reply to comment #9)
> Disregard the ssl use flag in my pecl-oauth example.  Technically it's
> optional but I removed the optional use flag part in DEPEND to make it
> required to prove my point.

If you want to test this behavior right now, emerge php 5.3 and php 5.4 with the "hash" use flag disabled.  Set your php targets in make.conf:

PHP_TARGETS="php5-3 php5-4"

Then emerge pecl-oauth 1.2.2 which is currently in portage, you will get the same behavior as I described above since pecl-oauth requires the hash flag to be enabled.
Comment 11 Roman Žilka 2013-03-17 21:51:35 UTC
I'll add my bit here, because I hit errors because of this behavior (i.e., only the highest slot being considered upon dep resolution) too. I too propose that it changes. I might also have an additional, related bug (if true, feel free to move that stuff to another bug#).

I use app-misc/anki-1.2.11 which depends on >=dev-lang/python-2.5[sqlite]. I don't have the flag "sqlite" turned on globally, but I used to have 'dev-lang/python sqlite' in package.use. Note the lack of version spec. Both of my pythons - python:2.7 and python:3.2 - were then compiled with +sqlite and all was well.

Then I decided to "emerge -e world". On that rare occasion, I try removing stuff from package.use to see if it is all still necessary. So I removed my line from package.use. I don't remember exactly what "emerge -p..." tests I ran then, but I ended up adding '>=dev-lang/python-3 sqlite'. I'm almost certain I did that because emerge had complained and suggested to add into package.use something like =python:3.2[sqlite]. Only the highest slot seems to count.

Now both "emerge -e" and "emerge -uDN --complete-graph --with-bdeps" were satisfied and I proceeded with the "emerge -e". First the pythons were merged and then anki, but its compile phase failed. I use python:2.7 as the main one - that's the default in Gentoo now - and sure enough, anki needs that python to have +sqlite. Python:3.2 with +sqlite, which emerge considers adequate, is useless. I had to add back 'dev-lang/python sqlite' and manually "emerge python:2.7 anki".

Now anki runs. When I remove the line from package.use again, "emerge -puDN world" wants to rebuild dev-lang/python-2.7.3-r2  USE="-sqlite*". That shouldn't happen. In case of php, Gentoo's default now is to install both :5.3 and :5.4, but use :5.3 as the main one. People might get analogous SNAFUs with that too. I think in Matthew's use case both php's should get +ssl and in my use case both pythons should get +sqlite, because only then can I switch between those two and need not fear that something breaks.

At this point I also get this strangeness:

********************************************************

# emerge -pv python:2.7 python:3.2

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

Calculating dependencies... done!
[ebuild   R    ] dev-lang/python-3.2.3:3.2  USE="gdbm ncurses readline ssl threads (wide-unicode) xml -build -doc -examples -ipv6 -sqlite* -tk -wininst" 0 kB
[ebuild   R    ] dev-lang/python-2.7.3-r2:2.7  USE="gdbm ncurses readline ssl threads (wide-unicode) xml -berkdb -build -doc -examples -ipv6 -sqlite* -tk -wininst" 0 kB

Total: 2 packages (2 reinstalls), Size of downloads: 0 kB

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/python:3.2

  (dev-lang/python-3.2.3::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (dev-lang/python-3.2.3::gentoo, installed) pulled in by
    >=dev-lang/python-2.5[sqlite] required by (dev-python/sqlalchemy-0.7.9::gentoo, installed)
    >=dev-lang/python-2.5[sqlite] required by (app-misc/anki-1.2.11::gentoo, installed)

!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

********************************************************

Where is the slot conflict? And to top things up:

# emerge -epv world|egrep '(/python-[23]|anki)'
[ebuild   R    ] dev-lang/python-2.7.3-r2:2.7  USE="gdbm ncurses readline ssl threads (wide-unicode) xml -berkdb -build -doc -examples -ipv6 -sqlite* -tk -wininst" 0 kB
[ebuild  NS    ] dev-lang/python-3.1.5:3.1 [2.7.3-r2:2.7, 3.2.3:3.2] USE="gdbm ncurses readline ssl threads (wide-unicode) xml -build -doc -examples -ipv6 -sqlite -tk -wininst" 8,015 kB
[ebuild   R    ] app-misc/anki-1.2.11  USE="graph sound -furigana -latex -recording" 0 kB

Now why :3.1? (Note that :2.7 and :3.2 are still in the system compiled with sqlite, both of them, and package.use is clean.)

Portage 2.1.11.52, amd64 hardened.
Comment 12 Zac Medico gentoo-dev 2013-03-19 07:06:00 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > And I don't like it because random dependencies are not the place to ensure
> > that.
> 
> Where is the proper place to ensure that?  Is there the possibility then
> that portage will be changed to accommodate for this?

What you're asking for is a dependency that's "greedy" for slots (borrowing the "greedy" term from regular expressions). You really can't express it using existing dependency constructs, you'll need an EAPI extension for this. You can file a bug for that and assign it to pms-bugs@gentoo.org.

(In reply to comment #11)
> # emerge -pv python:2.7 python:3.2
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R    ] dev-lang/python-3.2.3:3.2  USE="gdbm ncurses readline ssl
> threads (wide-unicode) xml -build -doc -examples -ipv6 -sqlite* -tk
> -wininst" 0 kB
> [ebuild   R    ] dev-lang/python-2.7.3-r2:2.7  USE="gdbm ncurses readline
> ssl threads (wide-unicode) xml -berkdb -build -doc -examples -ipv6 -sqlite*
> -tk -wininst" 0 kB
> 
> Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
> 
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
> 
> dev-lang/python:3.2
> 
>   (dev-lang/python-3.2.3::gentoo, ebuild scheduled for merge) pulled in by
>     (no parents that aren't satisfied by other packages in this slot)
> 
>   (dev-lang/python-3.2.3::gentoo, installed) pulled in by
>     >=dev-lang/python-2.5[sqlite] required by
> (dev-python/sqlalchemy-0.7.9::gentoo, installed)
>     >=dev-lang/python-2.5[sqlite] required by (app-misc/anki-1.2.11::gentoo,
> installed)
> 
> !!! Enabling --newuse and --update might solve this conflict.
> !!! If not, it might help emerge to give a more specific suggestion.
> 
> ********************************************************
> 
> Where is the slot conflict? And to top things up:

You requested a rebuild of python:3.2, but that conflicts with the dependencies of your installed packages. So, you'll have to change your package.use settings before you can rebuild.

> # emerge -epv world|egrep '(/python-[23]|anki)'
> [ebuild   R    ] dev-lang/python-2.7.3-r2:2.7  USE="gdbm ncurses readline
> ssl threads (wide-unicode) xml -berkdb -build -doc -examples -ipv6 -sqlite*
> -tk -wininst" 0 kB
> [ebuild  NS    ] dev-lang/python-3.1.5:3.1 [2.7.3-r2:2.7, 3.2.3:3.2]
> USE="gdbm ncurses readline ssl threads (wide-unicode) xml -build -doc
> -examples -ipv6 -sqlite -tk -wininst" 8,015 kB
> [ebuild   R    ] app-misc/anki-1.2.11  USE="graph sound -furigana -latex
> -recording" 0 kB
> 
> Now why :3.1? (Note that :2.7 and :3.2 are still in the system compiled with
> sqlite, both of them, and package.use is clean.)

This resembles bug 438502.
Comment 13 Ulrich Müller gentoo-dev 2020-02-28 11:13:58 UTC
No progress since 2013. Closing.