Bacula-users

Re: [Bacula-users] Bacula spec changes

2009-08-02 17:19:57
Subject: Re: [Bacula-users] Bacula spec changes
From: Scott Barninger <scott AT barninger DOT com>
To: Kern Sibbald <kern AT sibbald DOT com>
Date: Sun, 2 Aug 2009 17:19:48 -0400
Hello Kern,

Well, someone certainly needs to buy you a beer or two, that is an amazing 
amount of work for the time invested. Jack - are you listening? I will 
certainly give this a complete look and integrate it into the project builds. 
You have always been the team leader here and I am happy to work with your 
example. See below for my preliminary comments. Please note that I am writing 
now preliminarily without looking at anything.

On Sunday 02 August 2009 04:13:19 pm Kern Sibbald wrote:
> Hello Scott,
>
> I'd like to outline a bit of what I have done to the spec files, but first,
> I would like to say that I believe that I have taken into consideration all
> the points that you have raised to this point: the file is now simply
> bacula.spec and I have split bat, mtx, and the docs out into separate
> specs, which mean that the build for the main rpms is *much* faster.

We agree on the splits to be sure and if this means you have abandoned the 
idea of using the configure script to rewrite paths I can only say thank you 
for considering my opinion. I agree that we can dispense with the mtx 
sub-package as all major distros now package it. I'm also intrigued by your 
idea to simply incorporate bat rather than make it a separate package but I 
suspect we would be hounded by the folks who want to install a server without 
X.

>
> For those who read this: I am making this changes after discussing it with
> Scott not because there is anything wrong with the current spec, there are
> just some changes that are necessitated to accomodate for differences with
> way Bacula Systems will be packaging the Enterprise rpms.

Well, that's a nice way of saying that Kern took the time to eliminate a LOT 
of cruft that has accumulated in the spec file as time wore on and I never 
found the time to do.

>
> In addition to creating four spec files:
> bacula.spec
> bacula-docs.spec
> bacula-mtx.spec
> bacula-bat.spec
>
> I have made the following changes:
> - the gconsole, wxconsole, and tray-monitor code are now gone
>   If we need one of those we can always create another spec file
> - the bacula.spec file is considerably simpler because:
>   - gconsole, mtx, bat, docs, wxconsole, and the tray monitor
>     are removed

good riddance.

>   - I have remove almost all the library version dependences. The idea
>     is that we should rely on the OS packagers to ensure that the correct
>     libraries are loaded.

Here I would suggest some discussion. I have long thought about deleting the 
bloat of Requires: in the spec. RPM automatically inserts requires for 
specific library files and versions. If you are installing the package with a 
package manager (ie. yum or yast2) it will automatically solve and pull in 
dependencies. But if you download the package from us and attempt 
to 'rpm -ivh bacula-blah' then without the specific package requires it will 
give the user cryptic error messages that they will have difficulty solving. 
Thus I have long maintained the bloat of distro-specific package requires.

>   - I have made a few shortcut defines that reduce the length of some of
> the %if statements.
> - I have corrected a few of the places where passwords were edited in. 
> They were misedited in at least one place causing password failures.
> - I added new post processing code that uses the name of the machine
>   on which the package is installed.  This is used to make the daemon names
>   correspond to the installed machine name rather than the build machine
>   name.

Nice ;-)

> - The bat build now builds with Qt 4.3.2 rather than what is installed on
> the build machine. This should result in a much stabler bat.
> - I install all the man pages with the base package, which is what I think
> is the correct thing to do, even though the user may not install all the
> components -- at least he can know what exists.
> - I have certainly screwed up some of the older builds by the changes in
> the %ifs.

Therefore we should maintain the current spec file in some archive form 
perhaps. I'm not really worried about maintaining the older builds but I 
ocassionally get the odd email from the user who just can't stand to give up 
RH-7.3 and this would at least give them something to work from if it really 
mattered.

Example from the changelog:
* Sat May 16 2009 D. Scott Barninger <barninger AT fairfieldcomputers DOT com>
- fix libxml dependency for rh7 per Pasi Kärkkäinen <pasik AT iki DOT fi>

> - I haven't yet had time to actually test the binaries to see if they
> install and run correctly.
> - There are a number of additional changes that I need to integrate from
>   the Enterprise .spec, which corrects a good number of permission problems
>   when running the Dir and SD as bacula rather than root.
> - I seems to me that there was a version of bconsole in /usr/bin.  I
> deleted that code. It is now installed into /usr/sbin.  If someone also
> wants it in /usr/bin, we can add a hardlink.

I think you may have altered the code which used RH consolehelper to escalate 
to root which involved making a symlink in /usr/bin that called consolehelper 
which then called the console as root. I will have to look I think.

>
> There are probably a number of other points that I have forgotten about,
> but you will get the idea -- the problem is that I spent a week on this,
> and it is hard to remember everything I did -- some of the builds required
> 2 hours, so fixing a series of little errors takes many days.
>
> You can get the current code from the Source Forge git directory.  I've put
> everything into platforms/redhat, and left the suse,... as they were for
> the moment.
>
> Ideally, you (Scott) will embrace these spec files, build from them, and
> fix the remaining problems that are sure to exist.
>
> Best regards,
>
> Kern



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
<Prev in Thread] Current Thread [Next in Thread>