Portfile modification date checks vs. Portfile revisions

[Rainer Müller]

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