On Thu, Nov 29, 2007 at 11:17:16AM -0700, Brad Nicholes wrote: > The reason why I am making that suggestion is because if somebody wants a > static version then they should just continue using 3.0.5.
They will also need the bugfixes we are getting into 3.1.x, and since we said we won't maintain the 3.0.x branch anymore then they have no option but to use 3.1.x. even if we open a maintenance branch for 3.0.x (which I recommend regardless and will volunteer to support once I acquire the means to do so) there are other features than plugins which they might need as well, and so that wouldn't most likely work for all possible cases either. last, there is low "cost" in our side on keeping the static libraries around so I really see no reason to remove them now. (*) > Secondly, the static version is tied to an old version of APR 0.9.x which has > never been officially released by the ASF. http://www.apache.org/dist/apr/Announcement0.9.html > The only supported versions of APR outside of its use within the Apache httpd server itself are 1.x versions. and that is why APR 0.9.x is not dynamically linked and should remain that way, as there are no binary compatibility warranties of any kind for external users like us, even though I am sure that withing ASF no one will dare to break ABI compatibility there either as apache 2.0 and 1.3 depend on it and are both supported products. http://issues.apache.org/bugzilla/show_bug.cgi?id=42992 > Since there has been new work in APR 1.2 with regards to the multicast APIs > and other bug fixes and enhancement, it gets increasingly risky to stick with > an old pre-release version of APR. if I recall correctly multicast support for APR 0.9.x was actually added thanks to Matt as he implemented it for our tree first because ganglia 2.5.x supported only multicast (through other means) and a migration to 3.0.x (which used APR instead) without it wasn't even a consideration. now that 1.2 could be used instead and that doing so was needed for building a plugin architecture, the move was a no brainer. that doesn't mean though we will left our users needing static builds out in the cold as we didn't leave our users using multicast either. > In addition, I would like to see Gmetad ported on top of APR as well so that > it can take advantage of the portability advantages of APR. I'm not sure > that work going forward would include a static build capability. Certainly > not on APR 0.9.x anyway. that could be done in a way that is APR 0.9.x compatible, or we can of course update the srclib version to APR 1.2 (or whatever is needed) at that time, and keep the static build capability. if there is really no compatible way to do that and still keep the static build capability then it will be probably better just to drop it and delete at that time but since that project wasn't even in the ganglia 3.1.x wishlist I am assuming it is ganglia 4.x material anyway. Carlo * I made 1 patch to fix some APR 1.x specific parameters that were preventing trunk to build with the included APR 0.9.x, but it only required 5 minutes when looking at the APR 0.9.x documentation to use instead the backward compatible ones. ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
