From: Adolf Belka <ahb.ipfire@gmail.com>
To: development@lists.ipfire.org
Subject: Re: [PATCH] bacula: Update to 9.6.6
Date: Tue, 29 Sep 2020 15:08:48 +0200 [thread overview]
Message-ID: <1b7fc761-36f1-2157-a333-122c8c21e0a2@gmail.com> (raw)
In-Reply-To: <55A77FC1-6B54-4335-8EF0-BF487C45628B@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 6651 bytes --]
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(a)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(a)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.gz
>>>> - 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(a)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
>>>> cd $(DIR_APP) && make $(MAKETUNING)
>>>> --
>>>> 2.28.0
>>>>
prev parent reply other threads:[~2020-09-29 13:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 13:35 Adolf Belka
2020-09-28 15:13 ` Michael Tremer
2020-09-28 15:49 ` Adolf Belka
2020-09-29 8:38 ` Michael Tremer
2020-09-29 13:08 ` Adolf Belka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b7fc761-36f1-2157-a333-122c8c21e0a2@gmail.com \
--to=ahb.ipfire@gmail.com \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox