Strange Behavior

James Berry jberry at macports.org
Wed Dec 21 08:27:32 PST 2011


On Dec 21, 2011, at 6:24 AM, Jeremy Lavergne wrote:

>> This code is in opIntersection in base/src/port/port.tcl [1]. First, it
>> creates a map from the port names to the list index in $b. If a port
>> appears multiple times in this list, the last index is stored in the
>> array. This is clearly wrong as we would want to keep the first entry.
> 
> I'd recommend we simply do a check before [re]setting the port in the array:
> 
> if {[lempty [array get port $bitem]]} {
> 
> 
> lempty returns 1 if we get an empty list of matches back.
> 
> array get returns a list containing pairs of elements (using string
> match). If the array contains no elements then an empty list is returned.

Interesting. I wrote that code, though it's been a while.

The intersection code wasn't really written to consider multiple identical items, and frankly the concept of any order within those lists seems a little accidental, so I'd be a little leery of even assuming that order counts, especially given that the source of the ordering is some other operation. Though it might work in the case described here. 

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?

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.

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

James


More information about the macports-dev mailing list