Gioele Barabucci writes ("Bug#907313: Lack of guidelines on purging conffiles
in stateless packages"):
> Most of the current base programs still work in this way, but I suppose
> that it is only a matter of time before everything will switch to the
> stateless paradigm (t
On 28/08/2018 05:21, Russ Allbery wrote:
Guillem Jover writes:
I think the distinguishing factor here is whether a pathname is a
configuration file or a configuration fragments directory. So, I'd
say:
* configuration file → /etc/foo/foo.conf → remove on purge, even if
[…]
* configur
Guillem Jover writes:
> I think the distinguishing factor here is whether a pathname is a
> configuration file or a configuration fragments directory. So, I'd
> say:
> * configuration file → /etc/foo/foo.conf → remove on purge, even if
>the package did not ship a file there, because this is
On Sun, 2018-08-26 at 12:17:23 -0700, Russ Allbery wrote:
> Gioele Barabucci writes:
> > For instance, apache (the application) is configured by some stub conf
> > in `/etc/apache` that loads *.conf files from directories such as
> > `/etc/apache2/sites-enabled/`. The real files are usually in
> >
On Sun, Aug 26, 2018 at 12:11:55PM -0700, Russ Allbery wrote:
> > I don't think this (nice) new paradigm changes anything and do think
> > that all types of configuration files should be treated the same.
>
> > I'd suggest to close this bug as 'wontfix'.
>
> If we do want to recommend removing th
Gioele Barabucci writes:
> For instance, apache (the application) is configured by some stub conf
> in `/etc/apache` that loads *.conf files from directories such as
> `/etc/apache2/sites-enabled/`. The real files are usually in
> `/etc/apache2/sites-available/`.
> The purge process for the apac
Julien Cristau writes:
> Second, policy 10.7.3 seems pretty clear to me that purge ought to
> remove the package's configuration files, whether they're conffiles or
> not.
I just looked at this, and I think that's the *intent*, but I don't think
we succeed in being quite as clear as we might hav
Holger Levsen writes:
> I don't think this (nice) new paradigm changes anything and do think
> that all types of configuration files should be treated the same.
> I'd suggest to close this bug as 'wontfix'.
If we do want to recommend removing those files, we shouldn't close this
bug as wontfix,
On 26/08/2018 18:37, Julien Cristau wrote:
On Sun, Aug 26, 2018 at 12:41:48 +0200, Gioele Barabucci wrote:
the policy lacks guidelines on how to treat user-provided configuration
files during configuration purging in packages for programs that follow the
"stateless" paradigm (default in `/usr`,
On Sun, Aug 26, 2018 at 12:41:48 +0200, Gioele Barabucci wrote:
> Package: debian-policy
>
> Hello,
>
> the policy lacks guidelines on how to treat user-provided configuration
> files during configuration purging in packages for programs that follow the
> "stateless" paradigm (default in `/usr`,
Hello,
On Sun 26 Aug 2018 at 12:41PM +0200, Gioele Barabucci wrote:
> For example, apticron (the program) has recently switched to a stateless
> configuration. The default configuration is shipped in
> `/usr/lib/apticron/apticron.conf` and the local configuration is written
> by the sysadmin (if
On Sun, Aug 26, 2018 at 12:41:48PM +0200, Gioele Barabucci wrote:
> the policy lacks guidelines on how to treat user-provided configuration
> files during configuration purging in packages for programs that follow the
> "stateless" paradigm (default in `/usr`, override in `/etc`).
btw, I think the
Package: debian-policy
Hello,
the policy lacks guidelines on how to treat user-provided configuration
files during configuration purging in packages for programs that follow
the "stateless" paradigm (default in `/usr`, override in `/etc`). Should
they be removed? Should they be kept?
For ex
13 matches
Mail list logo
