An idea for distributing ports
Marc André Selig
mas at seligma.com
Wed Apr 4 06:10:44 PDT 2007
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.
More information about the macports-dev