Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 698232 - sys-apps/portage-2.3.76: strange keyword suggestion after slot conflict
Summary: sys-apps/portage-2.3.76: strange keyword suggestion after slot conflict
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: autounmask
  Show dependency tree
 
Reported: 2019-10-22 01:41 UTC by Michael Orlitzky
Modified: 2019-10-31 16:58 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Orlitzky gentoo-dev 2019-10-22 01:41:24 UTC
I'm not sure how best to describe this. I've been stuck trying to update @world for two days now, because portage just churns for an hour and then bails due to a conflict. But sadly, that's not the unusual part. This is:

  $ sudo emerge -uDN1 --backtrack=100 hakyll
  ...

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

  ...

  The following keyword changes are necessary to proceed:
   (see "package.accept_keywords" in the portage(5) man page for more details)
  # required by @__auto_slot_operator_replace_installed__ (argument)
  =dev-haskell/bytestring-builder-0.10.8.1.0 ~amd64


That last suggestion is a bit strange, because everything in the haskell overlay is already keyworded on my machine:

  $ cat /etc/portage/package.accept_keywords
  ...
  # Haskell overlay
  #
  # https://github.com/gentoo-haskell/gentoo-haskell
  #
  */*::haskell ~amd64


The packages that portage suggests keywording are being pulled in from that overlay, or at least could be. I mean, they exist in the overlay. So adding that line to package.accept_keywords should be a no-op. Why does portage suggest it? (And might it have something to do with my dependency resolution continually failing?)

I started actually adding those lines to package.accept_keywords, and it does affect something, because my error message changes. For example, after adding

  =dev-haskell/http2-1.3.1 ~amd64

and re-running emerge, portage told me to add

  =dev-haskell/http2-1.6.2 ~amd64

I did that, and now it's telling me to add the bytestring-builder line I quoted above. Both of those http2 ebuilds should already have been accepted, so something is fishy.

I'm trying with ACCEPT_KEYWORDS="~amd64" now (because for haskell packages that should also be a no-op), but who knows when the emerge command will finish. I'll report back.
Comment 1 Michael Orlitzky gentoo-dev 2019-10-22 12:57:34 UTC
(In reply to Michael Orlitzky from comment #0)
> 
> I'm trying with ACCEPT_KEYWORDS="~amd64" now (because for haskell packages
> that should also be a no-op), but who knows when the emerge command will
> finish. I'll report back.

This worked, portage was able to resolve whatever it needed to resolve and the emerge is now in-progress. So it looks like there's an issue resolving accept_keyworded deps (possibly only in overlays) during slot rebuilds?
Comment 2 Zac Medico gentoo-dev 2019-10-23 16:51:29 UTC
Very strange. It would be interesting to see how it behaves with --autounmask-keep-keywords (which is the default behavior in latest ~arch portage bug 658648).
Comment 3 Michael Orlitzky gentoo-dev 2019-10-26 14:02:26 UTC
(In reply to Zac Medico from comment #2)
> Very strange. It would be interesting to see how it behaves with
> --autounmask-keep-keywords (which is the default behavior in latest ~arch
> portage bug 658648).

I managed to get it down to a smallish test case. Adding --autounmask-keep-keywords does make the suggestion go away.

I'm including the output of three commands below,

  * emerge -puDN @world
  * emerge --autounmask-keep-keywords -puDN @world
  * An "ls" command that shows you that these packages do indeed exist in
    the haskell overlay on my machine right now (so there's no real need to
    add them to accept_keywords)

I should note that this time around, adding ACCEPT_KEYWORDS="~amd64" does NOT help, so maybe there is a real conflict and this is just a UI bug. I couldn't tell you why ACCEPT_KEYWORDS made it work before. Probably user error.


$ emerge -puDN @world

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

Calculating dependencies... done!
[ebuild  N    ~] dev-haskell/time-manager-0.0.0  USE="-doc -hoogle -hscolour -profile" 
[ebuild  r  UD~] dev-haskell/http2-1.6.3 [1.6.5]
[ebuild  r  U ~] dev-haskell/http2-2.0.3 [1.6.5]
[ebuild  r  U ~] dev-haskell/warp-3.3.3 [3.2.26]
[ebuild  r  UD~] dev-haskell/warp-3.2.11 [3.2.26]
[ebuild  rR   ~] dev-haskell/wai-app-static-3.1.6.3-r1 
[ebuild  rR   ~] dev-haskell/hakyll-4.13.0.1-r1 

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

dev-haskell/warp:0

  (dev-haskell/warp-3.3.3:0/3.3.3::haskell, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (dev-haskell/warp-3.2.11:0/3.2.11::gentoo, ebuild scheduled for merge) pulled in by
    <dev-haskell/warp-3.3:=[profile?] required by (dev-haskell/hakyll-4.13.0.1-r1:0/4.13.0.1::haskell, ebuild scheduled for merge)
    ^                 ^^^ ^                                                                                                                                                                                 

dev-haskell/http2:0

  (dev-haskell/http2-2.0.3:0/2.0.3::haskell, ebuild scheduled for merge) pulled in by
    >=dev-haskell/http2-2.0:=[profile?] required by (dev-haskell/warp-3.3.3:0/3.3.3::haskell, ebuild scheduled for merge)
    ^^                  ^^^                                                                                                                                                                        

  (dev-haskell/http2-1.6.3:0/1.6.3::haskell, ebuild scheduled for merge) pulled in by
    <dev-haskell/http2-1.7:=[profile?] required by (dev-haskell/warp-3.2.11:0/3.2.11::gentoo, ebuild scheduled for merge)
    ^                  ^^^ ^                                                                                                                                                                       


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by @__auto_slot_operator_replace_installed__ (argument)
=dev-haskell/warp-3.2.11 ~amd64

 * In order to avoid wasting time, backtracking has terminated early
 * due to the above autounmask change(s). The --autounmask-backtrack=y
 * option can be used to force further backtracking, but there is no
 * guarantee that it will produce a solution.



$ emerge --autounmask-keep-keywords -puDN @world

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

Calculating dependencies... done!
[ebuild  N    ~] dev-haskell/time-manager-0.0.0  USE="-doc -hoogle -hscolour -profile" 
[ebuild  rR   ~] dev-haskell/http2-1.6.5 
[ebuild  r  U ~] dev-haskell/http2-2.0.3 [1.6.5]
[ebuild  r  U ~] dev-haskell/warp-3.3.3 [3.2.26]
[ebuild  rR   ~] dev-haskell/warp-3.2.26 
[ebuild  rR   ~] dev-haskell/wai-app-static-3.1.6.3-r1 

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

dev-haskell/warp:0

  (dev-haskell/warp-3.3.3:0/3.3.3::haskell, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (dev-haskell/warp-3.2.26:0/3.2.26::haskell, ebuild scheduled for merge) pulled in by
    >=dev-haskell/warp-3.2:0/3.2.26= required by (dev-haskell/hakyll-4.13.0.1-r1:0/4.13.0.1::haskell, installed)
                          ^^^^^^^^^^                                                                                                                
    <dev-haskell/warp-3.3:0/3.2.26= required by (dev-haskell/hakyll-4.13.0.1-r1:0/4.13.0.1::haskell, installed)
    ^                 ^^^^^^^^^^^^^                                                                                                                                                      

dev-haskell/http2:0

  (dev-haskell/http2-2.0.3:0/2.0.3::haskell, ebuild scheduled for merge) pulled in by
    >=dev-haskell/http2-2.0:=[profile?] required by (dev-haskell/warp-3.3.3:0/3.3.3::haskell, ebuild scheduled for merge)
    ^^                  ^^^                                                                                                                                                                        

  (dev-haskell/http2-1.6.5:0/1.6.5::haskell, ebuild scheduled for merge) pulled in by
    <dev-haskell/http2-1.7:=[profile?] required by (dev-haskell/warp-3.2.26:0/3.2.26::haskell, ebuild scheduled for merge)
    ^                  ^^^ ^                                                                                                                                                                        


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.



$ ls $REPOS/haskell.git/dev-haskell/{time-manager,http2,warp,wai-app-static}
/var/cache/portage/distfiles/../repositories/haskell.git/dev-haskell/http2:
total 32K
drwxr-xr-x 2 mjo mjo 4.0K 2016-04-25 18:08 files
-rw-r--r-- 1 mjo mjo 1.1K 2017-03-07 18:57 http2-1.5.4.ebuild
-rw-r--r-- 1 mjo mjo 1.3K 2017-03-07 18:57 http2-1.6.2.ebuild
-rw-r--r-- 1 mjo mjo 1.1K 2017-04-10 08:05 http2-1.6.3.ebuild
-rw-r--r-- 1 mjo mjo 1.1K 2019-10-20 15:35 http2-1.6.5.ebuild
-rw-r--r-- 1 mjo mjo 1.2K 2019-10-20 15:35 http2-2.0.3.ebuild
-rw-r--r-- 1 mjo mjo 1.5K 2019-10-20 15:35 Manifest
-rw-r--r-- 1 mjo mjo  392 2016-02-09 08:58 metadata.xml

/var/cache/portage/distfiles/../repositories/haskell.git/dev-haskell/time-manager:
total 12K
-rw-r--r-- 1 mjo mjo 309 2019-10-20 15:35 Manifest
-rw-r--r-- 1 mjo mjo 359 2019-10-20 15:35 metadata.xml
-rw-r--r-- 1 mjo mjo 557 2019-10-20 15:35 time-manager-0.0.0.ebuild

/var/cache/portage/distfiles/../repositories/haskell.git/dev-haskell/wai-app-static:
total 20K
-rw-r--r-- 1 mjo mjo  942 2019-03-01 19:28 Manifest
-rw-r--r-- 1 mjo mjo  425 2019-08-13 14:23 metadata.xml
-rw-r--r-- 1 mjo mjo 1.9K 2017-03-07 18:57 wai-app-static-3.0.1.1.ebuild
-rw-r--r-- 1 mjo mjo 1.6K 2018-04-16 13:40 wai-app-static-3.1.6.2.ebuild
-rw-r--r-- 1 mjo mjo 1.8K 2019-10-20 15:35 wai-app-static-3.1.6.3-r1.ebuild

/var/cache/portage/distfiles/../repositories/haskell.git/dev-haskell/warp:
total 24K
-rw-r--r-- 1 mjo mjo 1.2K 2019-10-20 15:35 Manifest
-rw-r--r-- 1 mjo mjo  678 2019-03-01 19:28 metadata.xml
-rw-r--r-- 1 mjo mjo 1.9K 2018-04-22 09:18 warp-3.2.19.ebuild
-rw-r--r-- 1 mjo mjo 1.9K 2018-09-09 18:05 warp-3.2.24.ebuild
-rw-r--r-- 1 mjo mjo 1.9K 2019-03-01 19:28 warp-3.2.26.ebuild
-rw-r--r-- 1 mjo mjo 1.9K 2019-10-20 15:35 warp-3.3.3.ebuild
Comment 4 Zac Medico gentoo-dev 2019-10-26 19:55:04 UTC
It looks like it's having difficulty locating a valid solution and this leads it to try to unmask ::gentoo ebuilds (which are not matched by your "*/*::haskell ~amd64" package.accept_keywords config).

It's clear that you need <dev-haskell/warp-3.3 in order to satisfy a dependency of dev-haskell/hakyll-4.13.0.1-r1, so you could mask >=dev-haskell/warp-3.3 in order to limit the search space and help it converge on a valid solution (this will naturally prevent the dev-haskell/http2 slot conflict which was triggered by the dev-haskell/warp slot conflict).
Comment 5 Michael Orlitzky gentoo-dev 2019-10-31 13:57:28 UTC
(In reply to Zac Medico from comment #4)
> 
> It's clear that you need <dev-haskell/warp-3.3 in order to satisfy a
> dependency of dev-haskell/hakyll-4.13.0.1-r1, so you could mask
> >=dev-haskell/warp-3.3 in order to limit the search space and help it
> converge on a valid solution (this will naturally prevent the
> dev-haskell/http2 slot conflict which was triggered by the dev-haskell/warp
> slot conflict).

For the record this does work, but I was never expecting portage to be able to figure out my conflict on its own. It'd be nice, but I know it's a hard problem and the tree is a mess.

This suggestion is the only thing that portage did wrong IMO:

  The following keyword changes are necessary to proceed:
   (see "package.accept_keywords" in the portage(5) man page for more details)
  # required by @__auto_slot_operator_replace_installed__ (argument)
  =dev-haskell/warp-3.2.11 ~amd64
Comment 6 Zac Medico gentoo-dev 2019-10-31 16:38:34 UTC
(In reply to Michael Orlitzky from comment #5)
> This suggestion is the only thing that portage did wrong IMO:
> 
>   The following keyword changes are necessary to proceed:
>    (see "package.accept_keywords" in the portage(5) man page for more
> details)
>   # required by @__auto_slot_operator_replace_installed__ (argument)
>   =dev-haskell/warp-3.2.11 ~amd64

Yeah, maybe there's an easy way to make it discard unnecessary suggestions like this. Since this packages was involved in a slot conflict, that might serve as a good heuristic for discarding unnecessary suggestions.
Comment 7 Zac Medico gentoo-dev 2019-10-31 16:58:56 UTC
Another good heuristic could be that package instances from the same slot (like dev-haskell/warp:0::haskell) were masked by backtracking, but that's a side-effect from the slot conflict.