>>> On 5/16/2007 at 3:58 PM, in message <[EMAIL PROTECTED]>, "Bernard Li" <[EMAIL PROTECTED]> wrote: > Hi Brad: > > On 5/16/07, Brad Nicholes <[EMAIL PROTECTED]> wrote: >
... > > So what is the current state of the 3.0.x branch? Are your dynamic > library fixes in that branch? I would hope that we should release > 3.0.5 soon with static libraries and focus on 3.1.0. We've had some > webfrontend enhancements since we released 3.0.4. > The 3.0.x branch is the state of the Ganglia project before any of the dynamic library fixes were added. Since it was decided that the dynamic module functionality was a large enough leap to warrant a revision bump, 3.0.4/5 was moved into a branch and trunk continued with new development. A 3.0.5 release should be made from the branch and any webfrontend enhancements should be added to trunk and then backported into the branch. >> IMO, I think that we should rip all of the external libraries out of the > ganglia tarball and if we still want to distribute them, do it in a separate > tarball/RPM. That way we can be sure to install the external libraries in an > /opt/ganglia location that will be out of the way of any conflicting distro > libraries. Moving forward, the Ganglia binaries should be dynamically > linking to any external libraries for technical reasons and to avoid > redistributing forked external source. > > This is what Marcus from Novell recommended a while back, and I fully > support it. So let's see it implemented. > Trunk is in a state where the external libraries can easily be ripped out. The --enable-static-build configure parameter is the only thing that depends on the external library source that exists in /srclib. If we remove /srclib and remove the --enable-static-build parameter, Ganglia will no longer be dependant on any forked code. The next issue is whether to continue storing external library code in the Ganglia repository and providing a means to build and deliver the libraries. This can certainly be done as I suggested above, but it is just as easy to pull a tarball from the original project side and build and install it. Storing it the source in the Ganglia repository seems like a duplication of effort. > P.S. Can someone please take a look at the Makefile to see if we can > 'fix' the 'make clean' target? It is currently broken horribly... > unless of course this is an issue with the libs we package which will > be moot once we rip them out. > My guess is that the brokeness is due to the external libraries and will go away once they are removed. So the questions that need to be resolved are: [Y/N] Remove the external libraries from the repository trunk [Y/N] Continue to host the external library source in the Ganglia repository [Y/N] Provide a means (ie. configure, spec files) to build and deploy the external libraries in a /opt/ganglia location What do you all think? Brad ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
