Summary: | sys-apps/portage-2.2.18: slot conflict with -k, no slot conflict without -k | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Kobboi <gentoo> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | alexanderyt, esigra |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 300071 | ||
Attachments: | output.txt |
Description
Kobboi
2015-04-17 13:26:53 UTC
Created attachment 401456 [details]
output.txt
(14:36:05) Kobboi: is it an issue with portage or with the tree that with -k I get a slot conflict and without I don't? https://bpaste.net/show/160b7282b968 (14:39:18) floppym: That seems like a portage bug. (14:45:05) floppym: Kobboi: Maybe save a tarball of /var/db/pkg in case someone wants to look at it later. So, /var/db/pkg/ available on request (82MB tarball) Does it solve if you try it with --backtrack=30 as suggested in the emerge message? On one setup, where I am not using binary packages, I was also getting the sbcl-1.2.9 vs sbcl-1.2.10, but I worked around it because I really needed to. On the original setup, where I am using binary packages and I for sure was not getting the conflict when not using binaries (as opposed to using the first setup), setting a backtrace value of 50 worked (did not try any other value). So I guess, I am now in a situation where I can no longer give any useful feedback... |