Hi Artur, On 2015-09-14 16:22, Artur Szostak wrote: > After about a year's worth of experience with MacPorts, there is > something that I still do not understand: why is there no mechanism > to express version requirements in the dependency information for a > Portfile? I have been running into a number of situations where > upgrading or downgrading an individual port leads to an > inconsistent/incompatible combination of package versions. It seems > that unless you are busy hacking away at your system, the only > reasonable upgrade path is always: sudo port upgrade installed
I agree with you that versioned dependencies would help in certain situations. However, it also means maintainers would need to invest additional time and tests to find out the lowest/highest working version would be. As MacPorts only provides a single version of each software in the ports tree, keeping track of these compatibilities is actually quite hard. If we had versioned dependencies, we could add them once they are reported, but I do not think the project has the capacity to actively check for this before committing updates. FWIW, 'sudo port upgrade outdated' should be preferred. With the 'installed' pseudo-port ports will be parsed which takes some time. > To me, it feels like the MacPorts documentation is misleading the end > user to believe that upgrading/downgrading individual packages is a > routine and safe procedure, when my experience tells me otherwise. > Can anyone point me to the reason behind these design decisions? I doubt there ever was a design decision to leave it out. In the same way there is no way variants can be used in a dependency, this cannot be fixed without rewriting lots of the current MacPorts base. We have a project funded by Google Summer of Code this year to add a SAT solver, which will be a first step for more possibilities how dependencies are handled in the future. There should be no documentation telling you that leaving ports outdated is safe – only the latest version/revision of ports is supposed to work with each other. We should get that fixed. Rainer _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
