set port not to upgrade

db iamsudo at gmail.com
Fri Feb 17 16:13:34 UTC 2017


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. Or, how do you manage/rollback a broken application while updating, say, 50+ ports? I'm just curious.

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

> 
> On Feb 15, 2017, at 15:58, Clemens Lang wrote:
> 
>> On Wed, Feb 15, 2017 at 09:27:25AM +0100, db wrote:
>>> It is not, but a local portfile seems to also override a potential
>>> upgrade.
>>> 
>>> Any other ways? Should I open a feature request?
>> 
>> Not aware of any other ways. Feel free to open a ticket, but please
>> check for an existing one first.
>> 
>> MacPorts mode of operation also includes always upgrading dependencies
>> first, so a change like this might get complicated fast. Help would be
>> very welcome.
> 
> 
> I don't think this a feature we could/should implement. MacPorts doesn't currently differentiate between breaking and non-breaking port upgrades. If we implemented this feature, and you were able to exclude port X from upgrading, while still allowing ports P Q R S to upgrade even though they depend on X, then this might work (if the upgrade of X you are excluding is a non-breaking upgrade, such as a minor version upgrade), but it might cause havoc (if the upgrade of X you are excluding is a breaking upgrade, such as a major version upgrade that changes the library version number). We don't want to be responsible for providing support for untangling the breakage you would introduce in such situations.
> 
> Instead, we should focus our energy on fixing whatever problem is preventing you from upgrading X.
> 



More information about the macports-users mailing list