Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 540562 - sys-apps/portage: emerge fails to trigger slot operator rebuilds when an update triggers a conflict (solved by larger --backtrack setting)
Summary: sys-apps/portage: emerge fails to trigger slot operator rebuilds when an upda...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
: 549006 (view as bug list)
Depends on: 615680
Blocks: 300071 619102
  Show dependency tree
 
Reported: 2015-02-18 19:47 UTC by Amadeusz Żołnowski (RETIRED)
Modified: 2017-08-11 19:52 UTC (History)
5 users (show)

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


Attachments
portage-conflict.log (portage-conflict.log.xz,362.61 KB, application/x-xz)
2015-02-18 19:57 UTC, Amadeusz Żołnowski (RETIRED)
Details
emerge --info sys-apps/portage (portage.info,6.15 KB, text/plain)
2015-02-18 19:58 UTC, Amadeusz Żołnowski (RETIRED)
Details
portage-no-conflict.log.xz (portage-no-conflict.log.xz,421.26 KB, application/x-xz)
2015-02-18 20:45 UTC, Amadeusz Żołnowski (RETIRED)
Details
emerge --info portage (emerge.info,11.09 KB, text/plain)
2016-05-29 07:03 UTC, Andrew Savchenko
Details
emerge.slot-conflicts (emerge.slot-conflicts,2.91 KB, text/plain)
2016-05-29 07:06 UTC, Andrew Savchenko
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Amadeusz Żołnowski (RETIRED) gentoo-dev 2015-02-18 19:47:04 UTC
!!! All ebuilds that could satisfy "x11-base/xorg-server:0/1.17.0=" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-base/xorg-server-1.17.0::gentoo (masked by: )


Reproducible: Always
Comment 1 Amadeusz Żołnowski (RETIRED) gentoo-dev 2015-02-18 19:57:54 UTC
Created attachment 396858 [details]
portage-conflict.log
Comment 2 Amadeusz Żołnowski (RETIRED) gentoo-dev 2015-02-18 19:58:40 UTC
Created attachment 396862 [details]
emerge --info sys-apps/portage
Comment 3 Amadeusz Żołnowski (RETIRED) gentoo-dev 2015-02-18 20:01:02 UTC
--backtracking=30 solves the issue
Comment 4 Amadeusz Żołnowski (RETIRED) gentoo-dev 2015-02-18 20:06:03 UTC
--backtrack=30
Comment 5 Zac Medico gentoo-dev 2015-02-18 20:18:01 UTC
(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.
Comment 6 Amadeusz Żołnowski (RETIRED) gentoo-dev 2015-02-18 20:45:08 UTC
Created attachment 396880 [details]
portage-no-conflict.log.xz

with --backtrack=30
Comment 7 Zac Medico gentoo-dev 2015-02-18 21:01:28 UTC
(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)
    ^                  ^^
Comment 8 Zac Medico gentoo-dev 2015-05-09 16:53:05 UTC
*** Bug 549006 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Savchenko gentoo-dev 2016-05-29 06:59:30 UTC
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.
Comment 10 Andrew Savchenko gentoo-dev 2016-05-29 07:03:18 UTC
Created attachment 435678 [details]
emerge --info portage
Comment 11 Andrew Savchenko gentoo-dev 2016-05-29 07:06:20 UTC
Created attachment 435680 [details]
emerge.slot-conflicts

Full output of:

# emerge -DNuav @world --verbose-conflicts --backtrack=30
Comment 12 Zac Medico gentoo-dev 2016-05-30 23:30:44 UTC
(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).
Comment 13 Andrew Savchenko gentoo-dev 2016-06-04 16:44:17 UTC
(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).
Comment 14 Andreas K. Hüttel archtester gentoo-dev 2017-04-15 20:23:03 UTC
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!
Comment 15 Zac Medico gentoo-dev 2017-04-15 22:15:00 UTC
(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?
Comment 16 Andrew Savchenko gentoo-dev 2017-04-15 23:17:36 UTC
(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.
Comment 17 Andreas K. Hüttel archtester gentoo-dev 2017-04-16 13:50:31 UTC
(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 :).
Comment 18 Zac Medico gentoo-dev 2017-05-10 04:00:26 UTC
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).
Comment 19 Zac Medico gentoo-dev 2017-05-14 18:31:34 UTC
This default backtrack setting is now 10 in the master branch:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=cbf9f3c0167a68de7901b2a0992c2d0a264b9b22
Comment 20 Zac Medico gentoo-dev 2017-05-20 18:31:01 UTC
Fixed in portage-2.3.5.
Comment 21 Zac Medico gentoo-dev 2017-05-20 18:56:38 UTC
Actually this is in portage-2.3.6.