set port not to upgrade

[Ryan Schmidt]

On Feb 17, 2017, at 10:13, db wrote:

> I get your point, but wouldn't a warning during build phase suffice? Be it a leaf or node the port marked to not be upgraded. As of now, if port A, a leaf, doesn't compile due to a bug in my system version, the only feasible solution is to move the working Portfile to a local repo, or use a git checkout.

Let's take a specific example.

Let's suppose that you use GraphicsMagick, which links with webp.

webp was recently updated to 0.6.0:

https://github.com/macports/macports-ports/commit/a69f60e3695e87f628b7c7a6f2480e8e4fa056c4

This increased the major version number of the webp libraries. GraphicsMagick and anything else linking with the webp libraries is now broken and must be rebuilt. Therefore, in the next commit, I increased the revision of all such ports:

https://github.com/macports/macports-ports/commit/bb2433fa33857a0672c4971bd91808f804b2f673

Suppose that for whatever reason webp 0.6.0 did not install on your computer. Suppose that you noticed that GraphicsMagick was outdated, and that webp's failure was preventing GraphicsMagick from updating. Suppose that you decided to use your hypothetical feature to induce GraphicsMagick to upgrade, despite the fact that its dependency webp will not build.

All possible outcomes of this situation are undesirable.

Possibility 1. You cannot use our pre-compiled binaries for some reason, so MacPorts builds GraphicsMagick from source against webp 0.5.2. But the entire purpose of the update to GraphicsMagick was to rebuild it against webp 0.6.0, so rebuilding it now against 0.5.2 again is a waste of your time. If you later succeed in updating webp to 0.6.0, GraphicsMagick will be broken. If you have revupgrade set to its default rebuild mode, MacPorts will then rebuild it for webp 0.6.0. If you have revupgrade set to report or none, then GraphicsMagick will just be broken, and you might not know why, and you might ask us for help, which will be a waste of our time. The more time we spend answering questions about problems the user caused for themselves by doing things we don't recommend, the less time we have to actually work on improving MacPorts, so we don't really want to make it easier for the user to do things we don't recommend.

Possibility 2. You receive a pre-compiled binary of GraphicsMagick from our build server. It was built for webp 0.6.0, but you still have webp 0.5.2, so the updated binary you just downloaded is considered broken, and downloading that was a waste of your time. If you have revupgrade set to its default rebuild mode, MacPorts will then download the source code and rebuild GraphcisMagick for webp 0.5.2 as per Possibility 1 above, wasting more of your time. And if revupgrade is set to a different mode, then GraphicsMagick just stays broken until you upgrade webp to 0.6.0.


> Or, how do you manage/rollback a broken application while updating, say, 50+ ports? I'm just curious.

In my opinion, MacPorts doesn't really provide a good way to do that either. Supposing you successfully updated webp to 0.6.0, and successfully updated all ports that depend on webp, and then later found that GraphicsMagick did not actually work correctly with webp 0.6.0 and wanted to downgrade, you would have to know that you have to downgrade not only GraphicsMagick, and webp, but also everything else that links with webp. This might have further consequences for anything that links with those ports, and so on.

Really, MacPorts is designed for you to run the version of the ports that we currently provide, not an earlier version.

We try to keep the collection working as a whole. This is why some updates, like the update to icu that I'm working on in https://trac.macports.org/ticket/49614, take time. I'm not just going to commit an update to icu and let all ports that link to it be broken because icu got a new library version, nor am I just going to blindly commit a revbump to all the ports that link with it and hope they still build successfully. I'm going to test all that on my own system before committing, so that when I run into a port that does not build with the new icu, I can investigate and fix it before the problem is seen by users.

Sometimes we make a mistake and commit something that does not build or does not work properly. Sometimes we don't know about the mistake immediately, because the problem only occurs on certain OS versions or in certain other situations that we didn't encounter during our own testing. In those cases, we need to focus on fixing those problems, not on providing the user with ways of bypassing that problem and thereby causing a whole host of other problems.

-

MacPorts does already have a flag that tells it to continue with other ports even if it encountered an error in a previous port. Because this can lead you into the undesirable problems I mentioned above, you should not use this flag when upgrading or installing, and I'm not going to be more specific about what the flag it.