Hi
Bastian Blank bastian.bl...@credativ.de writes:
Control: reopen -1
On Wed, Nov 26, 2014 at 01:09:08AM +, 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
signature.asc
Description: PGP signature
