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
--
[email protected] mailing list
