Strange Behavior

[Jeremy Lavergne]

> If you want to enforce having a local port override the tree, what if you
> were to do that by enforcing that the database search for category:kde,
> etc, return only the first of any such items found?

It's not so much a local port as it is a local repository, where they're
controlled in sources.conf. Listing sources [default] or simply higher in
the list is suppose to give precedence.

> There are clearly other ways to generate a portlist which includes
> multiple identical ports: I'm not sure that "first wins" or "last wins" is
> always better.

In this instance, documentation does say first wins. What will we impact
by changes in this area of the code though?

> Another question I'll ask: at the level of the portlist, ports are
> identified only by name and version. Are these ports even distinct at that
> point? What are the name/version of the two ports in this case?
> ("fullname" as stored in a port entry in the portlist)?

I believe a single repository can have duplicates, otherwise we'd never
run into the web site update failing due to duplicate portnames. Granted I
was using two separate repositories, but the fact they're coalesced might
indicate we currently treat it as one giant repository without any checks
such as enforcing order.

In my case, any KDE package that was I was upgrading triggered this:
 * kde4-runtime @4.7.4_0 (from file://...)
 * kde4-runtime @4.7.3_0 (from ports.tar)