Hi, currently, we enforce that every change has to increment the revision, in order to force a rebuild by the user. But in fact, the current base code also checks the last modified date of the Portfile to see if it was changed since installation. See sample with a non-existing port `empty': ---8<---snip---8<--- $ touch Portfile $ port install [...] ---> Installing empty 1_0 ---> Activating empty 1_0 ---> Cleaning empty $ port install Skipping org.macports.activate (empty ) since this port is already active ---> Cleaning empty $ touch Portfile $ port install [...] ---> Installing empty 1_0 Error: Target org.macports.install returned: Registry error: empty @1_0 already registered as installed. Please uninstall it first. Error: Status 1 encountered during processing. --->8---snap--->8--- So it clearly rebuilds just because the modification date of the Portfile itself changed (it also issues a message in debug mode, but I did not want to post a whole debug log). And you will notice this first *after* compiling, which could be a long time for some ports. It already happened to me: I typed `port install' just to see a message after fetching and compiling that actually I already had that exact same port/version/revision/variant installed. So I am asking if this is still needed at all. I would rather see `port install' telling me that this port is already installed and I would have to use `port upgrade` to get a newer version. Also, currently it only works for the exact combination of port/version/revision/variants, if it differs it will install anyway. This could be extended to check if it is installed at all no matter which version or which variants are selected. And install can of course be forced with -f. I suppose this was introduced for Portfile developers, so that it always runs the target if the Portfile is newer, but that is not comfortable or users in my opinion. What do you think? How should this work? Rainer