On Mon, 30 Apr 2012 17:11:21 +0300, Uoti Urpala
<uoti.urp...@pp1.inet.fi> wrote:
Dmitry Nezhevenko wrote:
On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote:
> Wrong. Any program behavior change may require changing custom
> configuration, but such changes need not be accompanied by changes
in
> the default configuration file. Currently dpkg lacks any mechanism
to
You are talking about changing "default" values, right? Other cases
More generally about things not necessarily directly related to any
particular option. For example changing heuristics in the program,
which
may require using different options to override (even if the options
themselves didn't change).
> > With "etc-overrides-lib" it's not possible at all...
>
> This is not true either. You could develop tools that work in this
case.
Yeah. I agree. It's _currently_ not possible at all.
It is possible the with etc-overrides-libs behavior. Your
"_currently_
not possible" is about the current state of the Debian tools, not
about
etc-overrides-libs. My original point was exactly that the issues are
due to limitations of the existing Debian tools, not fundamental
problems with the etc-overrides-libs model itself.
It is entirely possible to manage configuration files from dpkg's
maintainer
scripts (postinst on 'configure' stage, and resp. postrm) as you find
fit,
or by means of ucf, and possibly in combination with debconf.
One can ship a bunch of configuration files in /usr/share/$pkg, or
rather /usr/share/doc/$pkg/examples/ to avoid redundancy,
and have them copied to /etc/$whatever or whatever is needed.
(this has been so for more than a decade)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/495ab64b83513d1b28f64662febb5...@spnet.net
