On 2010-09-14 22:32 , Ryan Schmidt wrote: > You're right, we don't have stable and unstable port trees. The > suggestion has come up several times in the past, but we hardly have > the manpower to keep our current single tree up to date; I fear > splitting the tree in two would only double the problem. I'm also > unclear how it is decided in such a system when a port is "stable".
I agree with Ryan. We certainly do not have the man power to provide two separate trees. Just follow the amount of open tickets [1], it's hard enough to deal with that already. We also have to deal a lot with disappearing and non-responsive maintainers for which we still don't have a better solution than the 3 week abandonement [2]. > You're also right, MacPorts doesn't have the capability for ports to > declare dependencies on a specific version of another port, only on a > port (whatever version exists). There's little need to add this > capability IMHO since MacPorts also doesn't have the ability to > install a specific version of a port, only the currently-available > version. I imagine adding this capability would be quite involved. In > any case, nobody has added it yet; if you are sufficiently interested > in having this feature, and are interested in driving its design and > development, you could write a proposal to the macports-dev list. Be aware that adding such a feature is not that easy as it means to rewrite the whole dependency algorithm and especially deal with the problem of solving conflicts (foo needs qux >1.0, bar needs qux <=1.0). Rainer [1] http://student.physik.uni-mainz.de/~reiffert/macports/ [2] http://guide.macports.org/#project.update-policies.abandonment _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
