On February 21, 2015 12:30:05 AM CET, "René J.V. Bertin" <[email protected]> 
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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to