On Saturday 15 May 2010 17:41:10 Phil Stracchino wrote: > After having messed around a bit with various configuration options in > 5.x to see what produces what results, I wish to propose that the > primary configure options in Bacula need to be revised. > > The Bacula executables can be logically divided into five component groups: > > - The director > - The storage daemon > - The file daemon > - The consoles > - The tools > > Right now, Bacula has a --enable-client-only configure option which, by > itself, does nothing; there is a build-dird option which can be > explicitly either disabled or enabled; there is a build-stored option > which can be explicitly either disabled or enabled; the tools are always > built if the stored is built; and the consoles appear to be always > built, period, although from an examination the Makefiles, it appears in > places that they should be built only if the client is built. There's > also the tray monitor, which isn't really (logically speaking) a > console, which can be explicitly disabled, but apparently not explicitly > enabled. The truth is, at present, bacula configure options are a > confusing, counterintuitive mess that seldom produces the expected > results on the first try. > > On top of this, there's the problem that if you build with > --enable-static, the build will fail and tell you that --enable-static > is incompatible with --enable-libtool, which it enabled automatically. > Plus we have the issue that the tools are always built with the stored, > which makes the stored de facto require installation of a database > engine whether or not it will ever be used on that machine. This is > producing a number of complains in various places. > > > I propose that these options be rationalized by making the five-group > component division above (plus the tray monitor) explicit, and replacing > the current client-only and enable/disable-stored/dird > stored-always-includes-tools (and therefore > stored-always-requires-a-DB-engine) component selection with the > following explicit enable options: > > --enable-all > --enable-client > --enable-consoles > --enable-director > --enable-stored > --enable-tools > --enable-tray-monitor > > If and ONLY if NONE of the individual components is specified, then > --enable-all would be assumed by default. Divided up this way, a > database engine would be required ONLY if building either the Director > or the tools. > > Further, I suggest that since --enable-static and --enable-libtool are > incompatible, but libtool is enabled automatically by default if found, > --enable-static should automatically imply --disable-libtool. I'm also > unconvinced that there is a good argument for the separate > --enable-static-fd --enable-static-cons... options; --enable-static > should, IMO, just apply to all components that you are building. (The > question of whether it's even possible to do a fully static build on > Linux any more needs examination, too. It's been suggested to me that > this may be a NSS/PAM issue.) > > > I think this would make it much easier for users to select which > components they actually want to build and install, reduce unnecessary > components built and installed on machines where they will never be > used, simplify building static installations, and eliminate the need to > install database engines and all of their dependencies on standalone > Storage hosts on which the DB engine will never be used. > > > Comments? Did I miss anything that should have been obvious?
Phil, This seems like a nice project, but a rather large project since to do it right, one would need to not only modify a lot of Bacula's Makefiles, one would need to rewrite a lot of the document and rewrite a lot of the packaging scripts. In addition, it is relatively complicated, because it must work with shared libraries, non-shared libraries, and static linking as well. That is a lot of stuff to change and test. If someone wants to provide full git patches: configure.in changes, Makefile changes, packaging script changes, and documentation changes, then we would be happy to see it all simplified. If anyone is going to take this on, please see me *before* starting. Best regards, Kern ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
