Why would a port use its own existence as an excuse to fail install?

[Matthew D. Fuller]

> So I'd guess the same sorta thing is making portmaster try to
> _install_ it for you, rather than _upgrading_ it.

Or, rather, not touch it at all.

A nice thing about portmaster is that it's smarter than portupgrade.
An annoying thing is that, to me anyway, that usually seems to take
the form of trying to outsmart me, and I don't take kindly to that
kinda crap from anything without thumbs   :p

In this case, I'd guess, portmaster does its thing of pulling lists of
"unmet" (by whatever criterion) dependancies of the new thing you're
installing/upgrading to, and building/installing them itself rather
than letting ports' own recursion handle it.  So building the port you
actually want to upgrade would say, hey, that qt4-clucene stuff is
already there, so nothing to do.  But portmaster notices (presumably
through the same mechanism pkg check -d is triggering) that, hey,
there's no port with that origin installed, so I'll build and install
it myself first.  Which fails, since it's already installed, thus...


Now, why the origin of the _package_ is up to date with reality, while
the origins of the dependancy links are wrong, is the root question.
Those moves (r338902, Jan 6) were before I pkg2ng'd this box, so maybe
it's just some bad interaction between MOVED and portupgrade's pkgdb
which would have done the fixup and pkgog[0] and pkgng.



[0] Appropriate nomenclature in the long run, I suspect.  Imagine the
day when 12- and 13-STABLE are common, and then one day you find an
8.x box that's been sitting untouched since now, and you have to bring
it up to date.  You try and look at the installed packages, and you
say "pkg...  oh god"   :)


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.