At Sat, 03 Jun 2006 22:20:25 +0200 Benno Schulenberg <[EMAIL PROTECTED]> wrote:
> Allan Gottlieb wrote: >> unmerge A >> merge B >> merge A > > When A is blocking B, the normal thing to do is to just unmerge A, > and then execute again the command that reported the blockage. > This is normally something like 'emerge -vaDu world'. If the > package you unmerged is still needed, it will then automatically > get remerged. I see. This would cover many cases. But the command original command could have been "emerge (perhaps --update) B". A might still be needed (e.g. it might have been in world). With (the updated) B merged an emerge of A could still be successful since the ebuild for A might behave differently with (the updated) B present. Another example would be the original command was 'emerge -vaDu world', but A was in world and is not depended upon by anything else. Since A was unmerged, it will not be remerged. I don't know if this occurs in practice. These examples are admittedly rather comtrived. My google search result (posted a few msgs ago) gave the three step sequence you quoted above. I agree that your proposed two step procedure is more likely to give better results. Is the following modification of yours better or worse. It does seem to cover an extra case, but may be too complicated to put in a wiki page When A is blocking B, the normal thing to do is to unmerge A, and then execute again the command that reported the blockage. This command is normally something like 'emerge -vaDu world'. If the package you unmerged is still needed, it will often automatically get remerged. However, if A was originally in world and not depended upon by anything else, it will not be remerged. If A is still needed it must be explicitly emerged. (With the, possibly updated, B now merged the ebuild of A may behave differently so that no blockage occurs.) allan -- gentoo-user@gentoo.org mailing list