| Summary: | sys-apps/portage: emerge fails to trigger slot operator rebuilds when an update triggers a conflict (solved by larger --backtrack setting) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Amadeusz Żołnowski (RETIRED) <aidecoe> |
| Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | alexander, bircoph, esigra, pacho, perl |
| Priority: | Normal | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=554838 https://bugs.gentoo.org/show_bug.cgi?id=615680 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 615680 | ||
| Bug Blocks: | 300071, 619102 | ||
| Attachments: |
portage-conflict.log
emerge --info sys-apps/portage portage-no-conflict.log.xz emerge --info portage emerge.slot-conflicts |
||
|
Description
Amadeusz Żołnowski (RETIRED)
2015-02-18 19:47:04 UTC
Created attachment 396858 [details]
portage-conflict.log
Created attachment 396862 [details]
emerge --info sys-apps/portage
--backtracking=30 solves the issue --backtrack=30 (In reply to Amadeusz Żołnowski from comment #4) > --backtrack=30 I see that with the lower --backtrack setting, it choked on this conflict: app-text/poppler:0 (app-text/poppler-0.31.0:0/50::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (app-text/poppler-0.30.0:0/49::gentoo, installed) pulled in by >=app-text/poppler-0.12.3-r3:0/49= required by (app-text/texlive-core-2014-r1:0/0::gentoo, installed) ^^^^^^ >=app-text/poppler-0.24:0/49=[cairo] required by (app-text/evince-3.14.1-r1:0/evd3.4-evv3.3::gentoo, installed) ^^^^^^ app-text/poppler:0/49=[cairo] required by (app-text/zathura-pdf-poppler-0.2.5:0/0::gentoo, installed) ^^^^^^ I'm curious to see the merge list that it produced with --backtrack=30. Created attachment 396880 [details]
portage-no-conflict.log.xz
with --backtrack=30
(In reply to Amadeusz Żołnowski from comment #6) > Created attachment 396880 [details] > portage-no-conflict.log.xz > > with --backtrack=30 I see that is successfully triggered the poppler rebuilds. At least some of the backtracking was due to this: WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: media-video/libav:0 (media-video/libav-11.2:0/10::gentoo, ebuild scheduled for merge) conflicts with >=media-video/libav-9.12:0/9=[abi_x86_64(-)] required by (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3:0.10/0.10::gentoo, installed) ^^^^^ <media-video/libav-10:0=[abi_x86_64(-)] required by (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3:0.10/0.10::gentoo, installed) ^ ^^ *** Bug 549006 has been marked as a duplicate of this bug. *** Hi,
looks like I have a similar issue here: I'm updating @world on rather old setup (@system and some other parts are already updated); and I have the following:
# emerge -DNuav @world --verbose-conflicts --backtrack=30
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
[...]
media-libs/glew:0
(media-libs/glew-1.13.0:0/1.13::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
(media-libs/glew-1.10.0-r2:0/1.10::gentoo, ebuild scheduled for merge) pulled in by
media-libs/glew:0/1.10= required by (games-arcade/supertux-0.4.0:0/0::gentoo, installed)
^^^^^^^^
Full output will be attached below. The important thing here that I have only list of slot conflicts here, no other conflicts are listed. I tried higher backtrack values: 50, 100 — they give different list of blockers, but nevertheless in contains them.
All conflicts has one common feature: they are caused by := (sub)slot operator depth where package A is already at its latest version (or slot version), so it is excluded by --update option, but it depends on package B which needs to be updated and such update will cause (sub)slot operator change.
To workaround this I had to use '--ignore-built-slot-operator-deps y' and now I see that deptree actually has some other blockers aside from slot conflicts, that can be (easily) fixed. Please note, that increasing backtrack value doesn't help me; at least increasing it to a sane value, maybe 1000 will help, but I'll have to wait a day for it to resolve :x
Another question is how to say emerge "upgrade these packages (e.g. -DNu @world), but force rebuilds of the following list, even if you don't want to rebuild them". This way I can just say something like --rebuild-force games-arcade/supertux for the example above to solve the issue instead of using '--ignore-built-slot-operator-deps y' for the whole tree. But I can't find such an option: there are only --rebuild-exclude and --rebuild-ignore. It would be nice to have --rebuild-force alike option, at least for debugging.
Created attachment 435678 [details]
emerge --info portage
Created attachment 435680 [details]
emerge.slot-conflicts
Full output of:
# emerge -DNuav @world --verbose-conflicts --backtrack=30
(In reply to Andrew Savchenko from comment #9) > To workaround this I had to use '--ignore-built-slot-operator-deps y' and > now I see that deptree actually has some other blockers aside from slot > conflicts, that can be (easily) fixed. That's a great "divide and conquer" approach! Splitting problems into manageable chunks certainly helps here. From now on I'm going to recommend that people having problems like this first use --pretend --ignore-built-slot-operator-deps=y in order to first resolve any issues that are not related to built slot operator deps. It might be useful for the dependency resolver to automatically do something like this internally! > Another question is how to say emerge "upgrade these packages (e.g. -DNu > @world), but force rebuilds of the following list, even if you don't want to > rebuild them". This way I can just say something like --rebuild-force > games-arcade/supertux for the example above to solve the issue instead of > using '--ignore-built-slot-operator-deps y' for the whole tree. But I can't > find such an option: there are only --rebuild-exclude and --rebuild-ignore. > It would be nice to have --rebuild-force alike option, at least for > debugging. Yeah, that would be useful. Maybe rebuild isn't necessarily the right word, since in some cases a suitable binary package might be available. So it's more like a --replace-force (simultaneously using --usepkg-exclude for the same atom would be equivalent to --rebuild-force). (In reply to Zac Medico from comment #12) > (In reply to Andrew Savchenko from comment #9) > > To workaround this I had to use '--ignore-built-slot-operator-deps y' and > > now I see that deptree actually has some other blockers aside from slot > > conflicts, that can be (easily) fixed. > > That's a great "divide and conquer" approach! Splitting problems into > manageable chunks certainly helps here. > > From now on I'm going to recommend that people having problems like this > first use --pretend --ignore-built-slot-operator-deps=y in order to first > resolve any issues that are not related to built slot operator deps. > > It might be useful for the dependency resolver to automatically do something > like this internally! Just for the record: after all non-subslot blockers were resolved, default --backtrack=3 was not sufficient, but --backtrack=10 done job well (I had not tested values in-between to find the minimal backtrack value). Ahem... since lots of people seem to be running into Perl upgrade issues again, Could we *PLEASE* get a larger *default* backtrack value in the next portage release? Doesn't sound like such a hard thing to do, and any "real fix" can still be done later... Thanks in advance! (In reply to Andreas K. Hüttel from comment #14) > Ahem... since lots of people seem to be running into Perl upgrade issues > again, > > Could we *PLEASE* get a larger *default* backtrack value in the next portage > release? The problem is that a larger default is not so friendly when people have unresolved configuration issues that cause it to waste a lot of time before it ultimately fails. So, the low default prevents it from wasting too much time in that case. In bug 615680 I have proposed a safeguard that should allow us to increase the default backtrack value while protecting people from the time wasting issue. > Doesn't sound like such a hard thing to do, and any "real fix" can still be > done later... The safeguard proposed in bug 615680 is very easy to implement, and that will make me much more comfortable about raising the default backtrack value. Do you like my proposal? (In reply to Zac Medico from comment #15) [...] > The safeguard proposed in bug 615680 is very easy to implement, and that > will make me much more comfortable about raising the default backtrack > value. Do you like my proposal? Absolutely. Raising backtrack values without this change (e.g. as it is now) will result in approximately 1.0 - 1.5 hours for full dep tree calculation on old hardware. (In reply to Zac Medico from comment #15) > The problem is that a larger default is not so friendly when people have > unresolved configuration issues that cause it to waste a lot of time before > it ultimately fails. So, the low default prevents it from wasting too much > time in that case. In bug 615680 I have proposed a safeguard that should > allow us to increase the default backtrack value while protecting people > from the time wasting issue. > > > Doesn't sound like such a hard thing to do, and any "real fix" can still be > > done later... > > The safeguard proposed in bug 615680 is very easy to implement, and that > will make me much more comfortable about raising the default backtrack > value. Do you like my proposal? The proposal sounds good to me. Let's try it out in ~arch (that's what it is for anyway :). Along with the patch for bug 615680, I've posted a patch to increase the default --backtrack value to 10 (see bug 615680, comment #5). This default backtrack setting is now 10 in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=cbf9f3c0167a68de7901b2a0992c2d0a264b9b22 Fixed in portage-2.3.5. Actually this is in portage-2.3.6. |
