In port interactive mode, pseudo-portnames corrupted after selfupdate

[hardwhack]

In interactive mode, after performing a selfupdate, several of the pseudo-portnames, e.g. inactive, obsolete both contain ~19K lines which I think is the entire list of available ports.

Here is an example of what I mean. Same thing happens with "list inactive."

[Lab/Transfac matrix] > list obsolete

[Lab/Transfac matrix] > selfupdate
---> Updating MacPorts base sources using rsync
MacPorts base version 2.3.0 installed,
MacPorts base version 2.3.0 downloaded.
---> Updating the ports tree
---> MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run

port upgrade outdated

[Lab/Transfac matrix] > list obsolete
AppHack @1.1 aqua/AppHack
AppKiDo @0.997 aqua/AppKiDo
AquaLess @1.6 aqua/AquaLess
ArpSpyX @1.1 aqua/ArpSpyX
AssignmentTrackerX @2.0beta3.1 aqua/AssignmentTrackerX
BGHUDAppKit @0.7 aqua/BGHUDAppKit
BigSQL @1.0 aqua/BigSQL
BiggerSQL @1.3.9 aqua/BiggerSQL
Books @3.2.5c aqua/Books

.... and onward for another ~19K lines

[ryandesign (Ryan Carsten Schmidt)]

I'm unable to reproduce that issue.

Also, note that:

• it is unusual to run selfupdate in interactive mode. Running selfupdate might update MacPorts. If so, MacPorts files may have been replaced/updated/removed, but you are still running the old version, which is not what you want; you want to be running the new version after selfupdating.
• the list command is almost always the wrong command to use. See wiki:FAQ#portlist. In this case, installed is the correct command to use.

[hardwhack]

I usually run individual port commands from the bash shell but sometimes my sudo times out so I wondered whether starting 'sudo port' once followed by calling everything else in interactive mode would save having to type my password.

I just tried again and noted one thing. If selfupdate actually finds an outdated port, 'outdated' correctly contains the outdated ports. If however I upgrade those ports and selfupdate again, then 'outdated' now contains the entire port list of 19K items.

I just found another method way to reproduce the same issue. In interactive mode, 'list outdated' returns nothing. But after the command 'outdated', 'list outdated' now returns the full list. Here is what I mean:

[~]$ port

MacPorts 2.3.0
Entering interactive mode... ("help" for help, "quit" to quit)
[Users/pjkim] > list outdated
[Users/pjkim] > outdated
No installed ports are outdated.
[Users/pjkim] > list outdated
AppHack @1.1 aqua/AppHack
AppKiDo @0.997 aqua/AppKiDo
..... lots more lines

Not a big deal because I will just stop using interactive mode and the problem/bug is absent when called non-interactively. My only concern is that this was an unexpected behavior that was possibly a real problem. After reading the FAQ you linked, I see that this is somewhat expected behavior, although the example above still puzzles me as it appears inconsistent/erratic.

[jmroot (Joshua Root)]

Replying to ryandesign@…:

• it is unusual to run selfupdate in interactive mode. Running selfupdate might update MacPorts. If so, MacPorts files may have been replaced/updated/removed, but you are still running the old version, which is not what you want; you want to be running the new version after selfupdating.

This isn’t a problem, if base is actually updated then it exits immediately afterward.

I can repro this, but only with pseudo-portnames that evaluate to an empty list. Looks like ‘list $foo’ is becoming just ‘list’ when $foo is the empty string, and of course ‘port list’ is documented to list all the ports. But it works properly at first for some reason.

[hardwhack]

Seems to be fixed in 2.3.1. Can probably close this ticket. Thank you to whoever fixed this.

[neverpanic (Clemens Lang)]

Still happens for me on trunk, and I'm pretty sure I didn't see a commit touching the relevant code for this.

[neverpanic (Clemens Lang)]

FWIW, I can also reproduce using

> list
> list outdated

or

> search
> list outdated

I think the problem occurs as soon as a single command without arguments has been executed because the flag that's used to tell port that an argument has been provided but it expanded to an empty list never gets reset.

[neverpanic (Clemens Lang)]

r121485, merged into release_2_3 in r121486. In the next release.

[hardwhack]

Replying to cal@…:

Still happens for me on trunk, and I'm pretty sure I didn't see a commit touching the relevant code for this.

You are correct. I jumped the gun. And thank you cal for fixing this.