Hi Bastian Blank <bastian.bl...@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
signature.asc
Description: PGP signature