Nope, openmotif depended on openmotif-config which was blocked by openmotif.
I tried unmasking one, the other, then both all to noavail.
Finally, in frustation I did emerge unmerge openmotif, emerge openmotif
and it just worked (pulling in openmotif-config in the process)
I for one would like to see portage be a bit smarter about this. It already calculates a dependancy list.
Would it be possible to detect the case where the blocker is part of the dependancy list (ie, will be installed anyway) and automatically offer to unmerge the conflicting package?
Or, is this a situation that should be handled with slots? Eg, slot 1 hols openmotif, slot 2 holds openmotif-config & newer openmotif.
I can't wait to see the hoop jumping xorg-x11-7.0 will require.
-dcm-
On 1/5/06, Neil Bothwick <
[EMAIL PROTECTED]> wrote:
On Thu, 5 Jan 2006 11:10:38 +0000, Tom Martin wrote:
> > To the portage developers, how could this be handled? Perhaps emerge
> > could somehow figure out the reason for such a conflict, and then
> > automatically unmerge the original package?
> Not really a question to the portage developers -- just unmerge
> openmotif (the blocker) and continue as normal.
I realise it is not possible to handle all conflicts, but
with some instances, like this one, the conflict is expected. even if
there were just a means to print a message if a package hits a block,
something like
if_blocked_by('openmotif')
ewarn "You must unmerge openmotif before proceeding"
--
Neil Bothwick
I am Tagline of Borg. Prepare to assimilate me.
