Re: [Bacula-devel] bacula-fd crashing - gcc 4.7

[Simone C. <neg...@gm...>]

On 24 May 2012 12:51, Kern Sibbald <ke...@si...> 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).