[PKG-Openstack-devel] Bug#770941: Bug#770941: closed by Thomas Goirand <zigo at debian.org> (Re: Bug#770941: closed by Thomas Goirand <zigo at debian.org> (Re: Bug#770941: nova-common - Overrides database config in nova.conf))

[Gaudenz Steinlin]

Hi

Bastian Blank <bastian.blank at credativ.de> writes:

> Control: reopen -1
>
> On Wed, Nov 26, 2014 at 01:09:08AM +0000, Debian Bug Tracking System wrote:
>> > It is a valid DSN.
>> In this:
>> postgresql:///nova
>> Where's the user and password? What's the hostname?
>
> User and password is not needed for ident auth, empty hostname is
> documented as using the unix socket.  And the documentation tells:[1]
>
> | These URLs follow RFC-1738, and usually can include username, password,
> | hostname, database name as well as optional keyword arguments for
> | additional configuration. In some cases a file path is accepted, and in
> | others a “data source name” replaces the “host” and “database” portions.
>
> So they _can_ include, not they _must_ include.  Also there are examples
> of this usage.
>
>> If theoretically, this *may* be a valid DSN, but practically, I don't
>> think you'd be using a DNS without a valid hostname, login and pass.
>
> It is valid in practice, otherwise it would not work in the first
> place.

I tend to agree with Bastian here. This change must be preserved. And to
me it also seems that having the database on the same host is a very
valid and not only theoretical setup. But basically this is beyond the
point (see below).

>
>> > And even if not, it must not change it.
>> The idea behind the policy is that a config script shouldn't change a
>> valid configuration, so that it is possible edit the configuration file,
>> and that change be kept when installing or upgrading.
>
> No, the idea is that the user have all right to change it to whatever he
> wants.  You can use ucf to do this task of merging config files.

Again I tend to agree with Bastian. I can't see anything in policy
(section 10.7.3) where the provision "local changes must be preserved
during a package upgrade" is somehow limited to configurations the
maintainer thinks are valid. While I can see some valid cases where you
can change or "upgrade" a clearly non functioning config file. This is
definitely not the case we are talking about.

>
>> P.S: Please don't reopen the bug. The config and postinst scripts are
>> doing exactly what I wanted them to do, and I feel like this is the
>> correct behavior. If you don't like the current behavior, I welcome you
>> to discuss it in the packaging list, but using BTS ping-pong isn't the
>> way to do so.

Please keep this bug open. There is obviously a bug somewhere in the
maintainer scripts.

>
> Well, I don't think so.  You can yourself refer to the ctte or I will.

I don't think we need the ctte to solve this. Can't we just work
together and find a solution?

Gaudenz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20141126/a36d17fe/attachment.sig>