Hi Michael,
Thanks for the feedback and clarification. I understand now and will follow your advice.
Will create new patches for the two changes remaining.
Thanks,
Adolf
On 29/09/2020 10:38, Michael Tremer wrote:
Hi,
On 28 Sep 2020, at 16:49, Adolf Belka ahb.ipfire@gmail.com wrote:
Hallo Michael,
These seem to be two different schools of thought…
My understanding was that rootfiles are supposed to have any files in /usr/lib/ with .so at the end of them prepended with #. Other programmes I have looked at in IPFire have libraries with .so.version-number so they don't end in .so and don't need to be commented out.
Normally you would have something like this:
libabc.so libabc.so.1 libabc.so.1.2.3
In that case, the linker would be searching for libabc.so which is a symlink to libabc.so.1 and that is the filename that would be linked into a binary that is linked against libabc at compile time.
Therefore, the libabc.so is no longer needed as nothing will be searching for it at runtime. The runtime linker will only be looking for libabc.so.1 which is a symlink to libabc.so.1.2.3.
However bacula has library files with.version-number.so so all of them end in .so and according to the rules I read in the Building Addons topic in the wiki, I should comment them all out but bacula would then fail to work.
Bacula follows a different approach, which potentially is the slightly incorrect one. But hey.
You have libabc-1.2.3.so which would also be linked into the bacula binary. That way, it will always be looking for a library with exactly that name. A patched and improved version would not work because it would have a different name (e.g. libabc-1.2.4.so) and not be found. Because of the symlink structure it would be used in the example above.
I am okay leaving the libraries in /usr/lib/ by removing the libdir command in the configure definition but then there will be libraries in that directory that end in .so and are not commented out in the rootfiles.
So that means, you cannot simply always remove all libraries that end in .so. The correct answer is: It depends.
In 99% of the cases you can have a look where the version number is and that will tell you.
Let me know if I should redo the patch using /usr/lib/ for the libraries.
Therefore I would suggest to keep bacula’s files in /usr/lib.
I would also suggest that you split these three changes (the backup fix, the version update and - formerly - the move to /usr/lib/bacula) as separate patches. That makes it easier to audit because the reviewer can see what changes belong together and which don’t.
Best, -Michael
Regards,
Adolf.
On 28/09/2020 17:13, Michael Tremer wrote:
Hello,
On 28 Sep 2020, at 14:35, Adolf Belka ahb.ipfire@gmail.com wrote:
- Update bacula from version 9.6.5 to 9.6.6 This is a minor bug release See https://sourceforge.net/projects/bacula/files/bacula/9.6.6/ReleaseNotes/ Source file available at https://sourceforge.net/projects/bacula/files/bacula/9.6.6/bacula-9.6.6.tar....
- Modified backup/includes file to backup the /var/bacula/working directory contents state filename could be varied if user modifies the port number for the file daemon
- Moved the library files from /usr/lib/ to /user/lib/bacula/ This ensures no .so files in /usr/lib/. Bacula has the .so at the end of all the library file names
Why is this an issue? Plenty of packages have that and those libraries might need to be in /usr/lib so the the runtime linker can find them. We do not want rpath compiled in.
Best, -Michael
Signed-off-by: Adolf Belka ahb.ipfire@gmail.com
config/backup/includes/bacula | 2 +- config/rootfiles/packages/bacula | 21 +++++++++++---------- lfs/bacula | 7 ++++--- 3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/config/backup/includes/bacula b/config/backup/includes/bacula index 92bce0eba..de1d9cc48 100644 --- a/config/backup/includes/bacula +++ b/config/backup/includes/bacula @@ -1,2 +1,2 @@ /etc/bacula/bacula-fd.conf -/var/bacula/working/bacula-fd.9102.state +/var/bacula/working/ diff --git a/config/rootfiles/packages/bacula b/config/rootfiles/packages/bacula index dc9179489..55488c61b 100644 --- a/config/rootfiles/packages/bacula +++ b/config/rootfiles/packages/bacula @@ -20,16 +20,17 @@ etc/bacula/bacula-fd.conf etc/rc.d/init.d/bacula #opt/bacula #opt/bacula/log -#usr/lib/bpipe-fd.so -usr/lib/libbac-9.6.5.so -#usr/lib/libbac.la -usr/lib/libbac.so -usr/lib/libbaccfg-9.6.5.so -#usr/lib/libbaccfg.la -usr/lib/libbaccfg.so -usr/lib/libbacfind-9.6.5.so -#usr/lib/libbacfind.la -usr/lib/libbacfind.so +#usr/lib/bacula +#usr/lib/bacula/bpipe-fd.so +usr/lib/bacula/libbac-9.6.6.so +#usr/lib/bacula/libbac.la +usr/lib/bacula/libbac.so +usr/lib/bacula/libbaccfg-9.6.6.so +#usr/lib/bacula/libbaccfg.la +usr/lib/bacula/libbaccfg.so +usr/lib/bacula/libbacfind-9.6.6.so +#usr/lib/bacula/libbacfind.la +usr/lib/bacula/libbacfind.so #usr/sbin/bacula usr/sbin/bacula-fd #usr/sbin/bbconsjson diff --git a/lfs/bacula b/lfs/bacula index 3201688f4..154b4a633 100644 --- a/lfs/bacula +++ b/lfs/bacula @@ -24,7 +24,7 @@
include Config
-VER = 9.6.5 +VER = 9.6.6
THISAPP = bacula-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = bacula -PAK_VER = 6 +PAK_VER = 7
DEPS =
@@ -47,7 +47,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = e58eb531483de98d0410b33e3ec3d96a +$(DL_FILE)_MD5 = 1ba9e2a2d979cbe9b5d76187f98418ac
install : $(TARGET)
@@ -85,6 +85,7 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-smartalloc \ --sysconfdir=/etc/bacula \
--libdir=/usr/lib/bacula \ --with-working-dir=/var/bacula/working \ --enable-client-only-- 2.28.0