i completely support the idea of completely removing the apr directory from the srclib directory.
i orginally included it because apr didn't support multicast so i had to alter the source. given that libapr has mcast sockets now, no need for our previous frankenstein apr. if people are installing/compiling ganglia from source, i think downloading apache apr isn't a big deal. if people want to statically or dynamically link... it should be up to them. we just need to make clear the plus and minuses of each approach. if people are installing using yum, apt-get, etc, then a dependency to libapr shouldn't be a big deal. let me know if you think ganglia users out there will be unhappy with the change. i think the world of package management is much better than it was 4 years ago when i decided to statically link everything into ganglia. -matt On Thu, 2007-04-26 at 12:17 -0600, Brad Nicholes wrote: > > >>> On 4/26/2007 at 11:06 AM, in message > <[EMAIL PROTECTED]>, "Bernard Li" > <[EMAIL PROTECTED]> wrote: > > Brad: > > > > I recommend you take a look at this thread in ganglia-developers: > > > > http://sourceforge.net/mailarchive/message.php?msg_id=36BEEFA2DF192944BF71E0 > > > > 72F7A5F465228FE7%40xchange1.phage.bcgsc.ca > > > > It offers a potential solution to platforms that do not have apr > > installed and also opinions of other distribution packagers regarding > > this issue :-) > > > > Thanks, > > > > Bernard > > > > Yep, the whole reason why I left it so that static linking with the Ganglia > copy of APR still works. Since I am fairly new to this project, I didn't > want to step on any toes too hard ;) Going forward I think that I am in > agreement with the idea of shipping two tarballs or at least providing > --with-libXXX=<lib_path> configure options so that the packager or user has > the option of how to build a complete Ganglia system. I really don't care > what the defaults for the configure options are. They could default to > dynamically linking the distro's libraries or statically linking the Ganglia > packaged versions. Configure can also be a little smarter and try to detect > if the library is already on the system before including and building the > Ganglia packaged version. Bottomline is that we can certainly make the > external libraries optional. > > One issue that needs to be addressed is if Ganglia builds and installs APR > (or any external library) onto a system that already has Apache or Subversion > installed, there is the potential for a problem with duplicate versions of > APR (expat, confuse, etc.). As it stands, Ganglia is not making sure that it > is not attempting to reinstall an existing library. Of course this was one > of the arguments for static linking. However the problem with static linking > at least APR, is that now that we have plugable metrics modules for GMOND, no > metric module would be able to use APR. Therefore, going forward, we need to > dynamically link APR. So the way to solve the problem would be to always > build the external libraries as DSO's if the appropriate library does not > already exist on the box. Then install the libraries in an /opt/ganglia/lib > location. > > Anyway, sounds like there has been some good discussion on this topic in the > past. So let's solve it and move forward. > > 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 > Ganglia-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-developers
