On 24 May 2012 12:51, Kern Sibbald <k...@sibbald.com> wrote: > I am pleased to hear that. I think Bacula is in RHEL 6 main, but if I am > not mistaken it is only the FD, which is pretty useless.
RHEL 6 has bacula 5.0.0 with some patches on and is not in a very good shape, it's missing the bpipe plugin, some features are disabled, etc. I've asked RH people to switch at least to Fedora's 5.0.3 but to no avail. > Could you email me your .spec files for Bacula and I will review them > and possibly make comments? Sure, all the spec files, patches and whatever is built in Fedora is in git: http://pkgs.fedoraproject.org/gitweb/?p=bacula.git;a=summary http://pkgs.fedoraproject.org/gitweb/?p=bacula-docs.git;a=summary Fedora 15-16 have Bacula 5.0.3, Fedora 17-18 (and 99% RHEL 7) have Bacula 5.2.6. Any comment is more than welcome. > Certain packagers are making serious mistakes by changing the object naming > conventions, and by doing or not doing a number of other things. > > One plea from me to you is: please put all of Bacula with the exception of > the Volumes it will write into /opt/bacula. Not doing so does an enormous > disservice > to users because they cannot easily backup Bacula nor can the easily change > versions. Spraying Bacula all over the system is very bad practice. > I am very aware of LSB, but the guys who wrote LSB were probably > not backup experts, I don't expect I will convince you (or the powers that > be), but > at least I can try. When I took my time to introduce something in Fedora I hit all the points very hard and got their point of view. It took me weeks to get a simple library in Fedora, people dissected licenses, compiler flags, timestamp preservation of files during installation, etc. In the Bacula case, files in /opt, RUNPATH on libraries/binaries, daemons that fork in systemd are explicitly forbidden by the Fedora packaging policies; there's no way to have a package built with binaries in /opt, it will be rejected by buildsystems, package review tools, distribution checking and assembly tools and especially by people. So many of the things that ship by default in the Bacula source code are not acceptable for inclusion; but that's the case probably also on Debian or other systems. Fedora / RHEL are a more strict choice as those are the only distributions that ship with SELinux turned on for everything, so many other things, compilator flags, and behaviours are as well confined. Unless you configure your system to run without explicit checks or compile packages on your own you're forced to leave gcc hardening options on; and that's intentional. http://fedoraproject.org/wiki/How_to_create_an_RPM_package https://fedoraproject.org/wiki/Packaging/SysVInitScripts https://fedoraproject.org/wiki/Packaging:Systemd In my previous job I ran Bacula Enterprise Edition with the packages provided (and you made me a lot of patches for Windows! - many thanks); so my option at the time to get support was simply "yum remove bacula-*" for all the packages and install the one provided by Bacula Systems. They worked perfectly fine but in a completely different logic; if I ran fedora-review, rpmlint, etc. on them I got tons of errors. It depends only on who's supporting the users; Redhat is supporting Bacula built the distribution way; so as long as people are free to package it as they see fit I think we're in the best direction. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
