Listing the ports that will be upgraded in advance
Clemens Lang
cal at macports.org
Sat Feb 21 09:38:24 PST 2015
On February 21, 2015 12:30:05 AM CET, "René J.V. Bertin" <rjvbertin at gmail.com> wrote:
>> That would require versioned dependencies, which MacPorts does not
>support.
>
>Not necessarily, I think. The easiest way to clamp to the current
>version would be to make a "shadow port dir that overrides the default
>one. Besides, what's wrong with "this port has a newer version but it's
>'held' so we simply skip the upgrade and hope the user knows what he is
>doing"?
Unfortunately, experience tells us that users often don't know what they are doing and which problems their actions might entail. We should not give users the possibility to shoot themselves in the foot,especially if doing so increases our support burden.
Believe me when I tell you what you want is impossible to achieve in a sane manner that doesn't break without version-aware dependencies. In fact, we occasionally see instances of this problem when people have made copies of ports to a local port tree and forget about them. We also saw an increased number of problems when rev-upgrade briefly deviated from the "upgrade all dependencies first" rule.
> I think we an rely on the version checking already implemented
>in the configure/cmake code, and possibly try a bit harder (where
>necessary) to present the actual error message to the user rather than
>"go check the log file".
That would still not cover cases where we modified the configuration of port X and want all its dependents rebuilt.
--
Clemens Lang
More information about the macports-dev
mailing list