Port updating instructions and portmaster -a

[Ade Lovett]

On Dec 01, 2010, at 00:53 , M K wrote:

> [major snippage to get to the point]
> 
> Given the time, the users could pick and choose which ports to update.

Herein lies the fundamental problem with upgrading ports, particularly those which affect a large number of other ports, of which I, amongst others, have a certain degree of understanding.

When it comes to testing such updates, they are done in a "clean room" environment, whether it is a local tinderbox, or a full -exp package build run.  Ports, and those that depend upon them, are built in natural order (ie: if A depends on B which depends on C, then the build order is C->B->A)

The ports tree contains bugs, naturally.  Implicit dependencies where explicit ones are needed are the most obvious.  "Oh, cool, configure script found <libfoo> so I shall link against it even though you didn't ask" is a little less common, but prevalent enough.  And so the list continues.

As such, the deeper down inside the chain a port is that has been updated, so the number of combinations and edge cases increases exponentially to the point where given that cpu time (compiling) is vastly cheaper than human time (answering "A didn't rebuild because I had Q, W, but not X"), it is simply easier to pull out the compilation sledgehammer and say "rebuild everything depending on updated port <bar>" or, in extreme cases, "rebuild _everything_" (I don't think this has happened yet, but most gettext upgrades, fortunately relatively few and far between, are pretty close contenders for this).

One should also note that whilst the capability exists, via ${LOCALBASE}/lib/compat/pkg, for old shared libraries to be kept, if you have ports Q and R, both depending on port V, and via the pick-and-choose method you choose to update V and one of Q or R, then Really Bad Things [tm] will start to happen.

In an isolated case of >one< end-user picking-and-choosing, then your approach would be viable with the caveats above.  Regretfully, we have many tens of thousands of end-users, with differing environments, and thus out of pure simplicity and saving of overall time, portmaster/portupgrade instructions occasionally come down via UPDATING in the shape of a really BIG hammer.

If someone[tm] could _provably_solve_ this upgrading problem, I'll make you famous (and take a 2% cut, I'm not greedy)

-aDe