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

[Alexander Golovko]

On Thu, 31 May 2012 18:16:03 +0200, Luca Capello wrote:
> 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.

I don't have any definitive answer yet, so will do as you say.


>
>>>> * 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 ;-)

fixed in c6de23f


>
>>>> * 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 ;-)

ucf like dpkg prompt user, when it need update changed by user config 
file.
ucf register managed files in /var/lib/dpkg/info/package.conffiles.


>
> Nevertheless, one option or the other is fine if, as you said, 
> package
> upgrades are safe WRT the configuration files.
>
> Thx, bye,
> Gismo / Luca

-- 
with best regards,
Alexander Golovko
email: alexandro at ankalagon.ru
xmpp: alexandro at ankalagon.ru