Re: Portfile modification date checks vs. Portfile revisions
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Portfile modification date checks vs. Portfile revisions
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Portfile modification date checks vs. Portfile revisions
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Portfile modification date checks vs. Portfile revisions
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. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Portfile modification date checks vs. Portfile revisions
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
