On 04.04.2007, at 12:14, Randall Wood wrote:
The idea behind the stable branch is this: When a portfile fails to parse in the unstable branch and causes port installation/upgrades to simply fail (like happened during the recent zlib problem) or causes other ports to break (like happened in the last gettext and libgtkhtml3 upgrades), it would be noticed by users of the unstable branch, and repair activities would prevent it from being picked up by the stable branch, so that once working changes were introduced and the port is left alone more than 2 weeks, it then becomes an upgrade in the stable branch.
Great idea! Two problems: (1) "Repair activities" after something is updated might not involve the offending port itself, but the port that was broken by it, or new compatibility ports made necessary by the update. These repair activities can take a while. Your suggestion, if implemented verbatim, would mean that the offending port (untouched since the problematic update) would become "stable" after two weeks, while the broken ports are still being updated. IOW, the broken ports would become broken in the stable tree as well, and people tracking stable would only be able to fix their systems after "repair activities" have subsided for two weeks. If we want to implement this, we need a "veto" system that would let us flag "offending ports" that are not broken in and of themselves, but still cause problems and breakage in other ports. gettext or guile or libgtkhtml3 would have been flagged "offending", with the flag being removed only after all affected ports have been repaired. Only two weeks after removal of the flag, the port can move to stable. (2) Some changes that affect several ports at once should really be handled as atomic operations. If a new version of aqbanking will only work with a new version of gnucash, updating the one without updating the other may break both. This is just what currently happens, but the existence of a stable branch (implying that things will work if you just track that one) should have a solution for it. Setting and clearing the "veto flag" or touching both ports at the same time might be a feasible workaround. Having versioned dependencies would be even better. Regards, Marc