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 <[email protected]> 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. >
