| Summary: | Versioned virtuals cause slot conflict when weak block dependencies could resolve with uninstall | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Peter Stuge <peter> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge -p1 '=dev-db/mysql-5.1*' '=virtual/mysql-5.1' --debug output | ||
Please post the emerge output. It solves the soft blockers automatically for me:
$ emerge -pv mariadb
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-db/mariadb-5.1.62 USE="community embedded ssl test -berkdb -big-tables -cluster -debug -extraengine -latin1 -libevent -max-idx-128 -minimal -pbxt -perl -profiling (-selinux) -static" 26,179 kB
[uninstall ] dev-db/mysql-5.1.62-r1 USE="community embedded ssl test -berkdb -big-tables -cluster -debug -extraengine -latin1 -max-idx-128 -minimal -pbxt -perl -profiling (-selinux) -static -xtradb"
[blocks b ] dev-db/mysql ("dev-db/mysql" is blocking dev-db/mariadb-5.1.62)
[blocks b ] dev-db/mariadb ("dev-db/mariadb" is blocking dev-db/mysql-5.1.62-r1)
Total: 1 package (1 new, 1 uninstall), Size of downloads: 26,179 kB
Conflict: 2 blocks
Maybe you're experiencing something like bug 365127. Make sure the USE flags are properly synchronized like this: emerge --nodeps -pv virtual/mysql dev-db/mariadb (In reply to comment #1) > Please post the emerge output. I can't anymore since I've finished the merge, but I can explain what is going on. > It solves the soft blockers automatically for me: Yes, because you're only changing between two providers for one and the same virtual/mysql-5.1. > $ emerge -pv mariadb > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ] dev-db/mariadb-5.1.62 USE="community embedded ssl test > -berkdb -big-tables -cluster -debug -extraengine -latin1 -libevent > -max-idx-128 -minimal -pbxt -perl -profiling (-selinux) -static" 26,179 kB > [uninstall ] dev-db/mysql-5.1.62-r1 USE="community embedded ssl test > -berkdb -big-tables -cluster -debug -extraengine -latin1 -max-idx-128 > -minimal -pbxt -perl -profiling (-selinux) -static -xtradb" > [blocks b ] dev-db/mysql ("dev-db/mysql" is blocking > dev-db/mariadb-5.1.62) > [blocks b ] dev-db/mariadb ("dev-db/mariadb" is blocking > dev-db/mysql-5.1.62-r1) > > Total: 1 package (1 new, 1 uninstall), Size of downloads: 26,179 kB > Conflict: 2 blocks I expect that you can reproduce the problem by emerge -pv \>=mariadb-5.3 and certainly emerge -pv \>= mariadb-5.5, but for 5.5 you'll need to add to package.unmask: >=dev-db/mariadb-5.5 =virtual/mysql-5.5 In my case I went from 5.0 to 5.5, but I believe 5.1 to any other minor version (even 5.0, although those are all masked now) will also hit the problem. > Maybe you're experiencing something like bug 365127. I think it's different. Portage only complains about the slot conflict between virtual/mysql-5.0 and virtual/mysql-5.5, there's no problem between the dev-db ebuilds, which is also why I can unmerge virtual/mysql-5.0 manually and then successfully go from only dev-db/mysql-5.0* to dev-db/mariadb-5.5* and virtual/mysql-5.5. The crux is perhaps that virtuals are treated "too much" like a real package? (In reply to comment #3) > I expect that you can reproduce the problem by emerge -pv \>=mariadb-5.3 and > certainly emerge -pv \>= mariadb-5.5, but for 5.5 you'll need to add to > package.unmask: > >=dev-db/mariadb-5.5 > =virtual/mysql-5.5 It works for me: $ emerge -p '>=dev-db/mariadb-5.5' '=virtual/mysql-5.5' These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N #] dev-db/mariadb-5.5.23 USE="community embedded ssl test -berkdb -cluster -debug -extraengine -latin1 -libevent -max-idx-128 -minimal -oqgraph -pbxt -perl -profiling (-selinux) -sphinx -static -systemtap" [ebuild U #] virtual/mysql-5.5 [5.1] [uninstall ] dev-db/mysql-5.1.62-r1 [blocks b ] dev-db/mysql ("dev-db/mysql" is blocking dev-db/mariadb-5.5.23) [blocks b ] dev-db/mariadb ("dev-db/mariadb" is blocking dev-db/mysql-5.1.62-r1) (In reply to comment #3) > I think it's different. Portage only complains about the slot conflict > between virtual/mysql-5.0 and virtual/mysql-5.5, there's no problem between > the dev-db ebuilds, which is also why I can unmerge virtual/mysql-5.0 > manually and then successfully go from only dev-db/mysql-5.0* to > dev-db/mariadb-5.5* and virtual/mysql-5.5. We'll need more information about the specifics of that slot conflict. I can of course reproduce the conflict by asking to switch the other way, while at the same time changing minor versions.
--8<--
# cat /etc/portage/package.unmask
dev-db/mariadb
dev-db/mysql
virtual/mysql
# emerge '<dev-db/mysql-5.5' -pv
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-db/mysql-5.1.62-r1 USE="community ssl -berkdb -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -pbxt -perl -profiling (-selinux) -static -test -xtradb" 25,723 kB
[ebuild UD ] virtual/mysql-5.1 [5.5] USE="-embedded -minimal -static" 0 kB
[blocks B ] dev-db/mysql ("dev-db/mysql" is blocking dev-db/mariadb-5.5.23)
[blocks B ] dev-db/mariadb ("dev-db/mariadb" is blocking dev-db/mysql-5.1.62-r1)
Total: 2 packages (1 downgrade, 1 new), Size of downloads: 25,723 kB
Conflict: 2 blocks (2 unsatisfied)
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
virtual/mysql:0
(virtual/mysql-5.1::gentoo, ebuild scheduled for merge) pulled in by
=virtual/mysql-5.1 required by (dev-db/mysql-posixmq-9999::stuge, installed)
(and 5 more with the same problem)
(virtual/mysql-5.5::gentoo, installed) pulled in by
=virtual/mysql-5.5 required by (dev-db/mariadb-5.5.23::gentoo, installed)
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.
#
-->8--
To clarify, the problem is not that there is a block and how the block is resolved - that works fine as far as I can tell. The problem is that I have to manually unmerge the virtual to avoid the slot conflict.
Maybe it's a problem in this portage version? I've only tested on 2.1.11.9.
Or maybe it makes a difference if you have no packages which depend on virtual/mysql? Note also that my dev-db/mysql-posixmq live ebuild has DEPEND=">=virtual/mysql-5", which is different from portage output "=virtual/mysql-5.1 required by (dev-db/mysql-posixmq-9999::stuge" - maybe this is a clue?
(In reply to comment #5) > The problem is that I have > to manually unmerge the virtual to avoid the slot conflict. Maybe it works better if you try something like this: emerge -p1 '=dev-db/mysql-5.1*' '=virtual/mysql-5.1' That may give it enough of a hint to solve the conflict automatically. (In reply to comment #6) > emerge -p1 '=dev-db/mysql-5.1*' '=virtual/mysql-5.1' > > That may give it enough of a hint to solve the conflict automatically. Same result. Do you have anything that DEPEND on virtual/mysql installed? > (In reply to comment #6) > > emerge -p1 '=dev-db/mysql-5.1*' '=virtual/mysql-5.1' > > > > That may give it enough of a hint to solve the conflict automatically. > > Same result. Please attach a debug log, created like this: emerge -p1 '=dev-db/mysql-5.1*' '=virtual/mysql-5.1' --debug &>debug.log > Do you have anything that DEPEND on virtual/mysql installed? Yes, I have dev-lang/php-5.4.5 installed, which has virtual/mysql in DEPEND. Created attachment 320654 [details]
emerge -p1 '=dev-db/mysql-5.1*' '=virtual/mysql-5.1' --debug output
(In reply to comment #9) > Created attachment 320654 [details] > emerge -p1 '=dev-db/mysql-5.1*' '=virtual/mysql-5.1' --debug output It shows that you have dev-db/mariadb in your world file. You can remove it like this: emerge --deselect dev-db/mariadb After that, the same command might resolve the conflict automatically. If not, create another debug log with your new world. (In reply to comment #10) > emerge --deselect dev-db/mariadb > > After that, the same command might resolve the conflict automatically. If > not, create another debug log with your new world. Yep, then it works. I'm unsure if that makes the bug invalid though? mariadb is in world because I made an intentional choice. If I didn't make the choice the first time one of them was installed (pulled in from php or elsewhere) then at least after I have switched once then I will have the dev-db/ package in world - unless I make sure to emerge it with -1, but should the user really have to keep that in mind for all packages that have virtuals? Maybe unconditionally skip adding virtual providers to world then? (In reply to comment #11) > mariadb is in world because I made an intentional choice. If I didn't make > the choice the first time one of them was installed (pulled in from php or > elsewhere) then at least after I have switched once then I will have the > dev-db/ package in world - unless I make sure to emerge it with -1, but > should the user really have to keep that in mind for all packages that have > virtuals? You probably don't want to use -1, as explained below. Just use emerge --deselect when you decide you want to switch to a different provider. > Maybe unconditionally skip adding virtual providers to world then? Well, it can good to have them in your world file because it provides a hint to the dependency resolver that you want to prefer a particular provider over the others (so it won't try to uninstall your preferred provider and replace it with another provider). |
sys-apps/portage-2.1.11.9 I have dev-db/mysql-5.0.70-r1 (and virtual/mysql-5.0) installed. I want to replace it with dev-db/mariadb-5.5.23 (and virtual/mysql-5.5) in one big go, with minimal downtime and without binpkgs. dev-db/mysql and dev-db/mariadb both inherit mysql-v2.eclass, where a weak block is added for the other respectively, since both can't be installed at the same time. Should be no problem since I want to replace. I would like portage to 1. build dev-db/mariadb, 2. install dev-db/mariadb and I guess virtual/mysql-5.5, and finally 3. uninstall dev-db/mysql-5.0.70-r1. The problem is that the (installed) virtual/mysql-5.0 and the (to-be-merged) virtual/mysql-5.5 both have SLOT="0", which makes perfect sense from the perspective of other ebuilds that DEPEND on a particular virtual version, but in my case I would like it if portage could notice the solution on it's own; If I manually unmerge virtual/mysql-5.0 (but keep dev-db/mysql-5.0.70-r1) then portage lets me replace mysql with mariadb while also changing minor versions: --8<-- # emerge -av mariadb These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N #] dev-db/mariadb-5.5.23 USE="community ssl -berkdb -cluster -debug -embedded -extraengine -latin1 -libevent -max-idx-128 -minimal -oqgraph -pbxt -perl -profiling (-selinux) -sphinx -static -systemtap -test" 28,621 kB [ebuild N #] virtual/mysql-5.5 USE="-embedded -minimal -static" 0 kB [uninstall ] dev-db/mysql-5.0.70-r1 USE="ssl -berkdb -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -perl (-selinux) -static" [blocks b ] dev-db/mysql ("dev-db/mysql" is blocking dev-db/mariadb-5.5.23) Total: 2 packages (2 new, 1 uninstall), Size of downloads: 28,621 kB Conflict: 1 block Would you like to merge these packages? [Yes/No] -->8-- Would it make sense for portage to have special treatment for slot conflicts on virtuals? If dependencies can be resolved if the installed virtual is temporarily disregarded then it would be nice for portage to automatically notice this and uninstall the virtual first, then install the new provider and new virtual, and finally uninstall the old provider. What do you think?