On 09-10-14 02:17, Henrique de Moraes Holschuh wrote:
On Wed, 08 Oct 2014, Paul Gevers wrote:
Thanks for the careful response. And no, as mentioned above, I didn't
mean to use dpkg-statoverride itself. dbconfig-common uses debconf and
ufc to manage the configuration files. However,
Paul Gevers writes (Re: Bug#720517: configuration files, ownership and
dpkg-statoverride):
On 07-10-14 15:40, Ian Jackson wrote:
Also I don't see in your references an explanation from anyone as to
why dbconfig-common does this.
I you mean with why: why is it implemented this way than
On 08-10-14 13:58, Ian Jackson wrote:
Paul Gevers writes (Re: Bug#720517: configuration files, ownership and
dpkg-statoverride):
On 07-10-14 15:40, Ian Jackson wrote:
Also I don't see in your references an explanation from anyone as to
why dbconfig-common does this.
I you mean with why
Paul Gevers writes (configuration files, ownership and dpkg-statoverride):
I am looking into dbconfig-common RC bug 720517 [1] and I was wondering
what the general idea is of maintainer scripts changing the permissions
and/or owners of configuration files and the use of dpkg-statoverride.
The
On 07-10-14 15:40, Ian Jackson wrote:
Also I don't see in your references an explanation from anyone as to
why dbconfig-common does this.
I you mean with why: why is it implemented this way than that is
exactly the question that I am asking myself looking at the code, if you
mean why does
On Tue, 07 Oct 2014, Paul Gevers wrote:
I am trying to come up with a patch against dpkg-statoverride that sets
the ownership and permissions upon creation, but not upon updates.
This really doesn't look like a good idea. In fact, it may well introduce
very confusing and likely dangerous
Hi,
I am looking into dbconfig-common RC bug 720517 [1] and I was wondering
what the general idea is of maintainer scripts changing the permissions
and/or owners of configuration files and the use of dpkg-statoverride. I
myself find it unacceptable that updating a package changes the
7 matches
Mail list logo
