port -u upgrade outdated

[Emmanuel Hainry]

Citando Ryan Schmidt :
> On Oct 4, 2007, at 15:44, Emmanuel Hainry wrote:
>
>> I must be misunderstanding what you want to achieve. I thought you
>> wanted a script that updates all your outdated ports and does not
>> leave inactive. In this case, there is no reason to use the -n flag :
>> you want the dependencies to be updated too if they are outdated,
>> don't you? (Or else why do you upgrade all outdated ports?)
>
> As explained, -n is recommended, and -f is necessary if ports depend on the 
> port being upgraded (that is, if the port has dependents):
>

Did not know it was recommended.

>> Then, I would do:
>>
>> While there exist an outdated port,
>> do
>> 	let foo be an outdated port,
>> 	'port update foo'
>> loop
>> port -f uninstall inactive
>>
>> Everything will have been updated in the good order, nothing will have
>> been built twice, the only argument against this I see is that it will
>> run port outdated a big number of times (and of course that some ports
>> depending on updated ones will be broken, which is why port update does
>> not uninstall by default in the first place...).
>
> By this method, everything will *not* be updated "in the good order"; 
> everything will be updated in the order in which "port outdated" prints 
> ports, which I believe is alphabetical order, and that's not necessarily 
> good. Consider that apache2 depends on apr and apr-util, and that apr-util 
> also depends on apr. "port outdated" would print these in the following 
> order: apache2, apr, apr-util.

Yes it will: I don't use -n which means port upgrade apache will first
upgrade the deps that are outdated so apr, then apr-util, then finally
apache (at least that is the behaviour port hash had each time I tried
upgrade).

Note that I do not use -f either, so the ports that are not outdated
won't be upgraded.

> So if you upgrade these in alphabetical order, apache2 will be
> upgraded
>first, and it will build against your old version of apr and apr-util.
>Then apr will be upgrated, and then apr-util will be upgrated and will
>link against the new version of apr. If the changes in apr and apr-util
>are minor (binary compatible with the previous release), this won't be
>a problem, but if the ABI changed, then apache2 will be broken after
>apr and apr-util are upgraded. Also, it may be a problem that apache2
>uses apr-util but apache2 and apr-util have been built against
>different versions of apr.

Humm, maybe you misunderstood my algorithm, at each step in the loop I
choose a port that is still outdated (which is why it issues so many
'port outdated', so after apache has been upgraded, apr and apr-util are
not to be reupgraded.

>
> Furthermore, "port upgrade foo" will fail to activate the new port,
> and fail to deactivate the old version of the port, if a port depends
> on the port foo. For example, "port upgrade apr-util" will fail
> because apache2 depends on apr-util. 

NO. port deeactivate and port activate do not complain if a port has
dependents! In fact, a dependency is considered as fulfilled even if
there is only an inactive port present!

>You need to force the upgrade with -f. However, apr-util also depends
>on expat, libiconv, db44 and sqlite3. Consider that these ports are not
>outdated. However, if you "port -f upgrade apr-util", apr, expat,
>libiconv, db44 and sqlite3 will all be rebuilt.

Really, -f is evil... I don't use it and from what you describe, I feel
you should not use it either.

>You don't need and therefore probably don't want this, which is why -n
>is used to specify that dependencies should not be followed: "port -nf
>upgrade apr-util".  If you add -u at this time to instruct MacPorts to
>uninstall the previous version before activating the new one ("port
>-nfu upgrade foo"), 

>you can skip the "port -f uninstall inactive" step at the end.
>

Well if you do as you do, you can skip it, if he does as I do, Thomas
will want this step.

The way I proposed works, just try it ;)


Emmanuel