Summary: | virtual/mailx resolution issue | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Carlo <gentoo-bugs> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Carlo
2021-12-25 20:57:45 UTC
1. What happens if you try do a world upgrade first? emerge -a -uvDU @world 2. Then depclean. 3. Then run it again? May be better for #gentoo. (Would also be interesting to know what happened if you temporarily masked mailutils). > 1. What happens if you try do a world upgrade first? > > emerge -a -uvDU @world# emerge -ap -uvDU @world works fine, but I fail to see what this should have to do with Portage not getting the dependency resolution right in the case I'm describing. > May be better for #gentoo. Well, I think it is a Portage bug I easily got around, but it's still a Portage bug, so I guess Gentoo Bugzilla is the correct address. > (Would also be interesting to know what happened if you temporarily masked mailutils). As I wiggled around this bug already, I can only imagine, Portage would have presented the same blocking issue with mail-client/mailx, as it is virtual/mailx's second || dependency. (In reply to Carlo from comment #3) > > 1. What happens if you try do a world upgrade first? > > > > emerge -a -uvDU @world# > > emerge -ap -uvDU @world > > works fine, but I fail to see what this should have to do with Portage not > getting the dependency resolution right in the case I'm describing. > I just wanted to see if the depgraph was clean and if it happened to resolve with a world upgrade which would be relevant if it failed with just plasma-meta. > > May be better for #gentoo. > > Well, I think it is a Portage bug I easily got around, but it's still a > Portage bug, so I guess Gentoo Bugzilla is the correct address. Sure. It wasn't clear if it was a support query or not and I wanted to poke more at the situation but it's gone now. > > > (Would also be interesting to know what happened if you temporarily masked mailutils). > > As I wiggled around this bug already, I can only imagine, Portage would have > presented the same blocking issue with mail-client/mailx, as it is > virtual/mailx's second || dependency. There's not much we can do to investigate this if you've already fixed it then. I wanted to know what would happen if you tried to force it to use s-nail and if it saw earlier on that mailutils would not be an option. Portage uses priorities. It's not clear to me how you've wiggled around it though. Anyway, this is probably a duplicate of bug 814335. *** This bug has been marked as a duplicate of bug 814335 *** |