An idea for distributing ports

[Marc André Selig]

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