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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
