Portfile modification date checks vs. Portfile revisions
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
On Feb 22, 2008, at 23:31, Rainer Müller wrote:
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?
Isn't it fine the way it works now? It's that way, I think, so that, if you already have foo installed, but now you want foo +bar, you can "sudo port install foo +bar", and it'll fetch and configure and build and destroot and install, however long that takes, and then it'll print the message that foo is already installed. Then you can "sudo port deactivate foo" and "sudo port activate foo +bar" and within a few seconds have the port swapped out.
Ryan Schmidt wrote:
Isn't it fine the way it works now? It's that way, I think, so that, if you already have foo installed, but now you want foo +bar, you can "sudo port install foo +bar", and it'll fetch and configure and build and destroot and install, however long that takes, and then it'll print the message that foo is already installed. Then you can "sudo port deactivate foo" and "sudo port activate foo +bar" and within a few seconds have the port swapped out.
But if I already got foo, I don't want to wait for `port install foo' take a long time just to tell me that I already got it. Maybe my request was not clearly phrased. If the Portfile modification date is newer than the installation date, "port install foo" will always begin to fetch and build, although you can't install the exact same port/version/revision/variant twice. Installing will just not succeed. And the time spent on building this was most probably wasted. By the way, if I want a port with additional variants, I use `port -unf upgrade foo +bar'. Rainer
On Feb 23, 2008, at 06:35, Rainer Müller wrote:
Ryan Schmidt wrote:
Isn't it fine the way it works now? It's that way, I think, so that, if you already have foo installed, but now you want foo +bar, you can "sudo port install foo +bar", and it'll fetch and configure and build and destroot and install, however long that takes, and then it'll print the message that foo is already installed. Then you can "sudo port deactivate foo" and "sudo port activate foo +bar" and within a few seconds have the port swapped out.
But if I already got foo, I don't want to wait for `port install foo' take a long time just to tell me that I already got it.
Maybe my request was not clearly phrased. If the Portfile modification date is newer than the installation date, "port install foo" will always begin to fetch and build, although you can't install the exact same port/version/revision/variant twice. Installing will just not succeed. And the time spent on building this was most probably wasted.
Not wasted. Just deactivate the one you got and then activate the new one.
By the way, if I want a port with additional variants, I use `port - unf upgrade foo +bar'.
I didn't know that worked.
On Feb 23, 2008, at 07:21, Rainer Müller wrote:
Ryan Schmidt wrote:
Not wasted. Just deactivate the one you got and then activate the new one.
Not possible. Install *failed*. You can't install the exact same version/revision/variants twice.
Oh. Um, yes. I see that now. Just ignore me while I go get some tea... maybe that will wake me up.
participants (2)
-
Rainer Müller
-
Ryan Schmidt