Bugzilla Bug 172812

Portage fails to merge because of blocked packages, even if the block will be
removed during the merge.

Calculating dependencies... done!
[blocks B     ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.3)
* snip *
[ebuild     U ] dev-python/pygtk-2.10.3 [2.8.2] USE="doc* opengl" 2,674 kB 
[ebuild  N    ] dev-python/gnome-python-2.16.2  USE="doc -debug" 393 kB 
[ebuild  N    ] dev-python/pygobject-2.12.3  USE="doc -debug" 332 kB 

As you can see, my 2.8 pygtk build is blocking pygobject (which I don't have
merged yet). Point is pygtk blocks pygobject because it's <= 2.9. What is crazy
here is that portage itself intends to merge pygtk 2.10. Portage doesn't seem
to understand that merging pygtk 2.10 will remove the (<= 2.9) block. The merge
order should work, but Portage refuses to proceed because of the block.

NB: Perhaps there is a good reason for this not to work. However, I think it's
a bug in the sense that it _could_ work, but it _doesnt_.

Reproducible: Didn't try

Steps to Reproduce:
1. Merge pygtk-2.8.2
2. Try to merge dev-util/meld-1.1.4
Actual Results:  
Portage should fail to merge with the following error message:

Calculating dependencies... done!
[blocks B     ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.3)


Expected Results:  
It should have merged it.

We can add an option giving it permission to uninstall packages automatically. 
It won't be the default behavior, since users may not want that behavior in
every case.

I'm probably missing something here... How exactly is this different from Bug
1343, plus how will unmerging something later on fix the previous depgraph? Or
you want to unmerge this and rebuild the depgraph after it's been unmerged? 

(In reply to comment #1)
> We can add an option giving it permission to uninstall packages automatically. 
> It won't be the default behavior, since users may not want that behavior in
> every case.
> 
How about just the permission to upgrade? It'd be far more sensible..

Umm sorry obviously what needs to happen is the resolver needs to take into
account that the package is being upgraded. Will this be fixed with the new
resolver?
(not spamming)

(In reply to comment #2)
> I'm probably missing something here... How exactly is this different from Bug
> 1343, 

That bug is concerned with optimization of a dependency graph for a _final_
state where all of the necessary constraints are satisfied for all of the
desired packages.

> plus how will unmerging something later on fix the previous depgraph? Or

View it as a series of dependency graphs that transition from an initial state
to a final state.

> you want to unmerge this and rebuild the depgraph after it's been unmerged? 

The dependency graph gradually evolves over time, one package at a time.  Some
dependencies can be temporarily unsatisfied during the process of evolution, as
long it's accepted that packages with unsatisfied dependencies will be
temporarily unusable.

(In reply to comment #5)

> The dependency graph gradually evolves over time, one package at a time.  Some
> dependencies can be temporarily unsatisfied during the process of evolution, as
> long it's accepted that packages with unsatisfied dependencies will be
> temporarily unusable.

sidenote> Sorry to interfere, I'm still trying to follow what's happening
around this bug.

Precisely. Without knowing the inner details, I feel that perhaps throwing a
"blocking action" while encountering the error is too harsh. 

So, in order to work around that fact, accepting the error, in your own words:
> it's accepted that packages with unsatisfied dependencies will be
> temporarily unusable.
These temporarily unusable packages also have to share this "unusability" with
all the packages that depend on it. Careful cycle detection should be made in
my opinion - or perhaps are there some facilities laying around doing just
that.

Cycles are specific, perhaps we should throw the error in that case because we
don't know how to merge these packages. (As a sidenote, there must be someone
relatively brain-dead who introduced such a potential thing in the portage tree
..)

Providing we have a forest of "temporarily disabled packages trees" laying
around, a simple counter updated on enable/disable actions provides the ability
to know at the end of the process if there are still disabled package trees
laying around, which can be considered as an error (or not, but we're not
talking features).

Waiting for a later-processed package in order to enable again a disabled
package tree seems tricky.  I don't have any idea on how to do this in regard
to portage.

*** Bug 180953 has been marked as a duplicate of this bug. ***

*** Bug 180953 has been marked as a duplicate of this bug. ***

Jakub said this was the same issue. In my case the block comes from a package
(idn) that's NOT even installed before running emerge and that's silly.

emerge -v bind

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS   ] sys-devel/automake-1.10  873 kB 
[ebuild     U ] net-dns/bind-9.3.4-r3 [9.3.2-r4] USE="idn ldap odbc ssl threads
-berkdb -dlz -doc -ipv6 -mysql -postgres -resolvconf% (-selinux)" 5,279 kB 
[ebuild  N    ] net-dns/idnkit-1.0  423 kB 
[blocks B     ] net-dns/idnkit (is blocking net-dns/bind-9.3.2-r4)

Total: 3 packages (1 upgrade, 1 new, 1 in new slot, 1 block), Size of
downloads: 6,574 kB

And no, unmerging bind before the update is NOT acceptable. What if it were
glibc, kernel or xorg?

(In reply to comment #9)
> [ebuild     U ] net-dns/bind-9.3.4-r3 [9.3.2-r4]
> [ebuild  N    ] net-dns/idnkit-1.0
> [blocks B     ] net-dns/idnkit (is blocking net-dns/bind-9.3.2-r4)

Apparently there's a file collision between idnkit and the older bind which
installed it's own copy of idnkit.  If you don't have collision-protect in
FEATURES, then you can probably get away without unmerging bind first.  The
--nodeps option will cause the blockers and all other dependencies do be
ignored.  Something like this might work for you:

emerge --oneshot --nodeps =sys-devel/automake-1.10 =net-dns/idnkit-1.0
=net-dns/bind-9.3.4-r3

*** Bug 181635 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> Precisely. Without knowing the inner details, I feel that perhaps throwing a 
"blocking action" while encountering the error is too harsh. 
> 
> So, in order to work around that fact, accepting the error, in your own words:
> > it's accepted that packages with unsatisfied dependencies will be
> > temporarily unusable.
> These temporarily unusable packages also have to share this "unusability" 
with all the packages that depend on it. Careful cycle detection should be made 
in my opinion - or perhaps are there some facilities laying around doing just 
that.

Er aiui cycles aren't hard to detect. Portage may well log this with eqawarn 
already. Also i think repoman should handle cycle detection.
> 
> Providing we have a forest of "temporarily disabled packages trees" laying 
around, a simple counter updated on enable/disable actions provides the ability 
to know at the end of the process if there are still disabled package trees 
laying around, which can be considered as an error (or not, but we're not 
talking features).
>
Er I don't know how that would tie into the resolver. Perhaps the new resolver, 
wherever it comes from, will answer some of that.

> Waiting for a later-processed package in order to enable again a disabled 
package tree seems tricky.  I don't have any idea on how to do this in regard 
to portage.

Nor do I tbh :-) Bear in mind however that the unsatisfied deps are only during 
the build, so using a binhost will obviate the concerns of enterprise users.

(In reply to comment #10)
> (In reply to comment #9)
> > [ebuild     U ] net-dns/bind-9.3.4-r3 [9.3.2-r4]
> > [ebuild  N    ] net-dns/idnkit-1.0
> > [blocks B     ] net-dns/idnkit (is blocking net-dns/bind-9.3.2-r4)
> 
> Apparently there's a file collision between idnkit and the older bind which
> installed it's own copy of idnkit.

I hope you'll agree with me that it shouldn't be an issue when upgrading,
because the target package set provides the same files as the old one.

> If you don't have collision-protect in
> FEATURES, then you can probably get away without unmerging bind first.  The
> --nodeps option will cause the blockers and all other dependencies do be
> ignored.  Something like this might work for you:
> 
> emerge --oneshot --nodeps =sys-devel/automake-1.10 =net-dns/idnkit-1.0
> =net-dns/bind-9.3.4-r3

Well, I don't think suggesting to use --nodeps is a serious answer to this
problem.

(In reply to comment #13)
> I hope you'll agree with me that it shouldn't be an issue when upgrading,
> because the target package set provides the same files as the old one.

That may be true in some cases.  It's possible to extend the blocker syntax to
indicate such cases, but no such syntax is currently supported.

Please translate "Er aiui" since I don't know any meaning for this and I can't
even guess ...

(In reply to comment #12)
> Er aiui cycles aren't hard to detect. Portage may well log this with eqawarn 
> already. Also i think repoman should handle cycle detection.
I'm not too familiar with portage innerds, but are 'eqswarn' some kind of
handlable 'exceptions'. Because if they are, it's cycle detection and so we can
think of a solution that handles just that. So my question is, are they ?


> > Providing we have a forest of "temporarily disabled packages trees" laying 
> > around, a simple counter updated on enable/disable actions provides the
> > ability to know at the end of the process if there are still disabled
> > package trees laying around, which can be considered as an error 

> Er I don't know how that would tie into the resolver. Perhaps the 
> new resolver, wherever it comes from, will answer some of that.

Is there any documentation around the current resolver somewhere, or perhaps
there is some knowledge hidden somewhere about that part that you could point
out.

> > Waiting for a later-processed package in order to enable again a disabled 
> > package tree seems tricky.  I don't have any idea on how to do this in 
> > regard to portage.

> Nor do I tbh :-) Bear in mind however that the unsatisfied deps are 
> only during the build, so using a binhost will obviate the concerns of
> enterprise users.

Yep I understand that this problem may seem minor for anyone not concerned by
the build. Even if there are good odds that some monkeys will be willing to
learn all the nice tricks from the wiki in order to supply our nice enterprise
users with the features. True question is : do portage will always need monkeys
?

(In reply to comment #15)
> Please translate "Er aiui" since I don't know any meaning for this and I can't
> even guess ...

$ emerge wtf; wtf aiui
AIUI: as I understand it

SCNR :P

(In reply to comment #6)
> Waiting for a later-processed package in order to enable again a disabled
> package tree seems tricky.  I don't have any idea on how to do this in regard
> to portage.

It's not worth trying support something like that with the current dependency
resolver.  I'm working on a new resolver that will be able to handle things
like this.  If you want to see some more advanced resolver code that's
available right now, have a look at pkgcore.  I don't know if it's capable of
doing what be want at the moment, but at least it's more advanced than
portage's current resolver.

*** Bug 188620 has been marked as a duplicate of this bug. ***

*** Bug 189842 has been marked as a duplicate of this bug. ***

Er, update[1] now works round this bug (by basically doing what a human would
do, ie scanning the list to see if the block is about to be cleared before the
blocked package.) Otherwise it gives the option to Clean the blocker or skip
the blocked package.

I still think there's scope for automating some of the stuff users are advised
to do, separately from the package manager; it's a lot easier to deal with
knowing portage is doing the right thing.

http://forums.gentoo.org/viewtopic-t-546828.html -- yes you can email me with
bugs (NB it only ever runs emerge, so it's not doing anything you can't do
manually [in terms of affecting installation])

This is fixed in 2.1.5_rc7.

* Blockers are now resolved automatically in many more cases
  than before.  When it's safe, blocked packages are uninstalled
  automatically so that users are no longer inconvenienced with the
  task. Automatically uninstalled packages are displayed in the merge
  list, marked "uninstall" and highlighted in red. With the --tree
  option enabled, it's possible to see which package(s) caused other
  ones to be automatically uninstalled.

(In reply to comment #21)
> This is fixed in 2.1.5_rc7.

Congratulations ! This is great news ! Thanks for the hard work; I understand
this required quite some time for some of you guys.

*applauds*

looks like portage has had a much-needed AI injection.

It's currently helping me sort out a server that hasn't been updated in so long
that I moved it from ~x86 to x86 and it still wants to update everything!

amazing work guys, thanks :)