set port not to upgrade

[db]

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

As I said, I do get your point. Nevertheless, I still think that something could be done. As of now I can locally duplicate a portfile, which has the effect of completely overriding the rsync tarball and not being notified of any available upgrades online. There seems to be no means to coordinate both. Let me use your example with GraphicsMagick - although the version numbers might not be accurate.

Assume I have GraphicsMagick @1.3.25_2 dependent on webp @0.5.2 and that syncing shows that GraphicsMagick rev 3 and webp @0.6.0 are available. Upgrading outdated ports would start with webp from 0.5.2 to 0.6.0 and succeed, then GraphicsMagick from rev 2 to 3 and fail. If MacPorts could record working dependencies for requested ports, it could first try the steps you described by downloading the binaries, next building from source, and eventually giving the option to, and this is my thought, locally branch the recorded dependency by adding new interdependent ports webp @0.5.2_L -> GraphicsMagick @1.3.25_2_L - but on next synchronisation, it would try to upgrade GraphicsMagick's next version with webp currently @0.6.0 or its next version. It'd be like a trial and error depth search backwards and forwards to get an older or updated working binary.

That said, I don't actually expect the devs to change the design of MacPorts, but search for some feasible workaround as is. I do manually maintain a couple of broken ports locally until problems are solved, and this I could automatise.

In a previous message you said you use a git checkout of the complete ports tree. Although I know how it works, I barely use git and MacPorts would be a reasonable excuse for using it more often. What's your experience with it and MacPorts? Could you mention any caveats for a use case like the above?

On 17 Feb 2017, at 21:54, Ryan Schmidt <ryandesign at macports.org> wrote:

> 
> 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.
> 
> 
>