Page MenuHomeFreeBSD

Upgrade Bacula to 9.0.3
AbandonedPublic

Authored by dvl on Aug 24 2017, 10:48 PM.

Details

Reviewers
ler
Summary

There are significant changes to the linking options.

I've created and installed the binaries. Simple jobs have run successfully.

I am wondering about the previous patches and why we had them.

Of special note:

I'll bring in Larry Rosenman, who worked on those patches. I think the issue relate more to upgrading and building and running.

At present we have:

$ ldd /usr/local/sbin/bacula-dir
/usr/local/sbin/bacula-dir:
	libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8008ac000)
	libz.so.6 => /lib/libz.so.6 (0x800ab6000)
	libbacfind-9.0.3.so => /usr/local/lib/libbacfind-9.0.3.so (0x800ccd000)
	libbacsql-9.0.3.so => /usr/local/lib/libbacsql-9.0.3.so (0x800edb000)
	libbaccats-9.0.3.so => /usr/local/lib/libbaccats-9.0.3.so (0x80110a000)
	libbaccfg-9.0.3.so => /usr/local/lib/libbaccfg-9.0.3.so (0x801312000)
	libbac-9.0.3.so => /usr/local/lib/libbac-9.0.3.so (0x801520000)
	libm.so.5 => /lib/libm.so.5 (0x801785000)
	libthr.so.3 => /lib/libthr.so.3 (0x8019b0000)
	libwrap.so.6 => /usr/lib/libwrap.so.6 (0x801bd7000)
	libssl.so.9 => /usr/local/lib/libssl.so.9 (0x801de0000)
	libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x802200000)
	libc++.so.1 => /usr/lib/libc++.so.1 (0x802675000)
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x802934000)
	libc.so.7 => /lib/libc.so.7 (0x802b52000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802f06000)
	libpq.so.5 => /usr/local/lib/libpq.so.5 (0x803114000)
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x803345000)

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 11253
Build 11627: arc lint + arc unit

Event Timeline

dvl edited the summary of this revision. (Show Details)
dvl added a subscriber: des.
ler added a subscriber: ler.

This looks good to me. Looks like they fixed their stuff.

This revision is now accepted and ready to land.Aug 24 2017, 11:21 PM

One additional consideration: not everyone will want to move from Bacula 7 to Bacula 9 immediately.

I will probably svn cp the existing Bacula ports to bacula7 ports (e.g. sysutils/bacula7 will come from the existing sysutils/bacula). I will do this before upgrading to Bacula 9.

sysutils/bacula-server/files/patch-src_filed_Makefile.in
8

Does the position of $(LDFLAGS) matter?

Most of the patches are like this.

The 9.0.3 code looks like this:

bacula-fd: Makefile $(SVROBJS) ../findlib/libbacfind$(DEFAULT_ARCHIVE_TYPE) ../lib/libbaccfg$(DEFAULT_ARCHIVE_TYPE) ../lib/libbac$(DEFAULT_ARCHIVE_TYPE)

@echo "Linking $@ ..."
$(LIBTOOL_LINK) $(CXX) $(WLDFLAGS) $(LDFLAGS) -L../lib -L../findlib -o $@ $(SVROBJS) \

Do I really need to move $(LDFLAGS) to be after findlib?

In D12122#251626, @dvl wrote:

One additional consideration: not everyone will want to move from Bacula 7 to Bacula 9 immediately.

I will probably svn cp the existing Bacula ports to bacula7 ports (e.g. sysutils/bacula7 will come from the existing sysutils/bacula). I will do this before upgrading to Bacula 9.

If you keep adding versionned ports, it would probably be better to only have versionned ports, sysutils/bacula7 and sysutils/bacula9...

But changing the version of a port by an incompatible version is really not a good idea. We stopped doing that for lang/perl5 -> lang/perl5.XX years ago for exactly that reason.

In D12122#251755, @mat wrote:

But changing the version of a port by an incompatible version is really not a good idea. We stopped doing that for lang/perl5 -> lang/perl5.XX years ago for exactly that reason.

I do not understand what this means: "But changing the version of a port by an incompatible version"

I did some tests on FreeBSD 11.0 with poudriere and everything builds fine. I haven't yet been able to test it in a production environment.

My only comment is that this upgrade changes the database for bacula. Should we:

  1. Notify the user and give them instructions
  2. Just run the upgrade for them
  3. Wait for them to figure it out on their own
dvl edited edge metadata.

Add database upgrade information to pkg-message

This revision now requires review to proceed.Aug 27 2017, 3:31 PM

I did some tests on FreeBSD 11.0 with poudriere and everything builds fine. I haven't yet been able to test it in a production environment.

My only comment is that this upgrade changes the database for bacula. Should we:

  1. Notify the user and give them instructions
  2. Just run the upgrade for them
  3. Wait for them to figure it out on their own

See recent change to pkg-message.in

Thank you.

In D12122#251801, @dvl wrote:
In D12122#251755, @mat wrote:

But changing the version of a port by an incompatible version is really not a good idea. We stopped doing that for lang/perl5 -> lang/perl5.XX years ago for exactly that reason.

I do not understand what this means: "But changing the version of a port by an incompatible version"

It means you want to change the port sysutils/bacula-server from 7 to 9, which are not compatible. You even said "people will want to stay at version 7". So people running pkg upgrade will ben in a world of pain trying to figure out wtf is happening to their bacula server that just stopped working.

So do not change the version of sysutils/bacula-server, keep it at version 7, and add a sysutils/bacula9-server that is at version 9. And then, from now on, only add versioned versions.

In D12122#252086, @mat wrote:
In D12122#251801, @dvl wrote:
In D12122#251755, @mat wrote:

But changing the version of a port by an incompatible version is really not a good idea. We stopped doing that for lang/perl5 -> lang/perl5.XX years ago for exactly that reason.

I do not understand what this means: "But changing the version of a port by an incompatible version"

It means you want to change the port sysutils/bacula-server from 7 to 9, which are not compatible. You even said "people will want to stay at version 7". So people running pkg upgrade will ben in a world of pain trying to figure out wtf is happening to their bacula server that just stopped working.

So do not change the version of sysutils/bacula-server, keep it at version 7, and add a sysutils/bacula9-server that is at version 9. And then, from now on, only add versioned versions.

I like this idea. Thank you.

Events have overtaken this. We have sysutils/bacula9-server now.