[pkg-bacula-devel] Current status of merging development2 branch

[Luca Capello]

Hi Alexander!

On Wed, 30 May 2012 23:19:23 +0200, Alexander Golovko wrote:
> On Wed, 30 May 2012 13:57:34 +0200, Luca Capello wrote:
>> On Sun, 27 May 2012 02:40:22 +0200, Alexander Golovko wrote:
>>> /var/lib/bacula/log:
>>>  - removed (packages now builded with correct log dir)
>>
>> While at it, we should also considering migrating to /run, thus
>> depending upon initscripts (>= 2.88dsf-13.3):
>>
>>   <https://wiki.debian.org/ReleaseGoals/RunDirectory>
>>
>
> yes, we should do this.

OK, let us try to do that for wheezy.

>>> /usr/share/doc/bacula-common/examples/nagios/check_bacula/Makefile.gz:
>>>  - added (but subject for remove)
>>
>> Would it be better to provide a separate nagios-bacula-plugin,
>> coordinating that with the Debian Nagios Team?
>>
>>   <http://pkg-nagios.alioth.debian.org/>
>>
>
> Yes, but there are 3-rd party nagios plugins additional, that will be
> well to include in this package too.
> It is subject to discuss too.

Ops, I think I was not completely clear: nagios-bacula-plugin would be
built by the bacula source package, thus removing the need to ship the
above Makefile.  Obviously, discussing with the Debian Nagios Team would
be welcomed to be sure the nagios-bacula-plugin is in sync with the
Nagios setup in Debian.

>>> /etc/bacula/bconsole.conf:
>>>  - added (subject for remove?)
>>
>> Why?  That file is mandatory, so we should provide it anyway.
>
> Because this file generates by postinst script.

Thank you for the explanation, I missed it.

>>> /usr/share/man/man8/bregex.8.gz,
>>> /usr/share/man/man8/bwild.8.gz:
>>>  - added manpages
>>
>> I would replace them with upstream's versions as quilt patches:
>>
>>   <http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/manpages/bregex.8>
>>   <http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/manpages/bwild.8>
>>
>
> Yes, this my miss, i didn't check that upstream already add this
> manpages.

No problem, fixed:

  <http://anonscm.debian.org/gitweb/?p=pkg-bacula/bacula.git;a=commitdiff;h=042cf896725fed331c3aeb74ddb6981bdf411c45>

>>> /usr/bin/bconsole, /usr/sbin/bacula-console:
>>>  - bconsole was shell wrapper, but now vanilla bconsole search it
>>> config in the same place,
>>>    so this wrapper removed. for compatibility provided simlink, so
>>> no
>>> changes for users
>>
>> I think that bconsole should stay in /usr/sbin given that upstream
>> install it there:
>>
>>
>>
>> <http://anonscm.debian.org/gitweb/?p=pkg-bacula/bacula.git;a=commitdiff;h=d92858c57ec47449e5ce49b81e27af026a77a098>
>>
>>
>> <http://anonscm.debian.org/gitweb/?p=pkg-bacula/bacula.git;a=commitdiff;h=1fab6a25a5af0806b09692e0a696f4a9d2d0f146>
>>
>
> But maybe we want to provide symlink in old place until post-wheezy?
> Or maybe we change bconsole path when update to 5.2.x?

If we provide any symlink then we are oblige to announce that to the
users when they call /usr/bin/bconsole, which means adding another
wrapper to output something like:
=====
$ bconsole
WARNING: you called /usr/bin/bconsole.

This was a Debian-specific hack and it will be removed once wheezy has
been released.  Please use /usr/sbin/bconsole instead.
=====

Also given that /etc/bacula/bconsole.conf has ownership root:bacula,
simply having bconsole in /usr/bin/ does not mean that any user can
start it.

However, while checking where bat is installed I found out that it is
installed in /usr/bin/ as well, so either we move everything to
/usr/sbin/ (and provide symlinks until post-wheezy) or we leave
everything in /usr/bin/ (and remove /usr/sbin/bacula-console
post-wheezy).  Upstream seems to install everything in /usr/sbin/, so I
would follow upstream.

>>> * d77e917 Fix errors in man pages
>>>     APPLIED
>>
>> This should be pushed upstream, I will do later on.
>
> Yes, i didn't do this, because manpages still contain errors. This
> commit only fix lintian errors.

OK, I will wait then ;-)

>>> * a4382f0 Properly set logdir
>>>     APPLIED
>>
>> Only in development2 branch :-(
>
> hmm. current master branch contain this changes.

Yeah, sorry, I meant "it was present only in the development2 branch and
not in the development branch", a result of:

  <mid:87vcjsnuzi.fsf at gismo.pca.it>
  <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/2012-May/000242.html>

>>> * f968df9 Install conffiles, don't mess with them
>>>     REJECTED
[...]
>> At a first view Hauke's approach is more Debian-like: /etc files are
>> conffiles (see `dpkg-query -s dpkg`), so they should be treated as
>> such.
>>
>
> You are right partially.
> Debian-like is not "conffiles", but safe process of package updating.
> Dpkg conffiles is only one of methods for solve config update problem.
> In our case ucf is much more better for this purpose.

I see two advantages of dpkg-conffiles: first, you are prompted during
upgrades and, second, they are listed in a central places, i.e.
/var/lib/dpkg/info/dpkg.conffiles.  I know about ucf, but I have never
played with it and I still think that this should have been implemented
in dpkg, but this is another story ;-)

Nevertheless, one option or the other is fine if, as you said, package
upgrades are safe WRT the configuration files.

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20120531/dad566d0/attachment.pgp>