Strange Behavior

[James Berry]

On Dec 21, 2011, at 8:46 AM, Jeremy Lavergne wrote:

>> 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)

I checked in a change to opIntersection, which makes sure the two lists being passed to opIntersection are unique. Can you verify that fixes your problem?

James