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 Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 [email protected] [email protected] [email protected] Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
