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

[Luca Capello]

Hi Alexander!

On Fri, 01 Jun 2012 17:11:33 +0200, Alexander Golovko wrote:
> On Thu, 31 May 2012 18:16:03 +0200, Luca Capello wrote:
>> 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.

Basically, if we follow upstream what we need is:

1) install everything as upstream
2) provide symlinks for the old locations
3) explain everything in NEWS.Debian
4) after wheezy, remove the symlinks

>> 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:
>>>>> * 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

Thank you, should I forward upstream or have you already done it?  In
this latter case, please also update the patch with the upstream bug
number.

>>> 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.

Thank you for the explanation :-)

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/20120602/80bb2540/attachment.pgp>