On Mon, 30 Apr 2012 14:44:42 +0300, Uoti Urpala
<uoti.urp...@pp1.inet.fi> wrote:
Hi,
Dmitry Nezhevenko wrote:
On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
> Marco d'Itri wrote:
> > - configuration files in /etc/ overriding configuration files in
/lib/,
> > to work around the inferior configuration files handling of
RPM
>
> I'm not convinced that the traditional Debian way of directly
editing
> package-created files under /etc would be preferable. I think the
> etc-overrides-lib alternative is technically superior in many
ways: the
> original version is kept in a known location, it's trivial to
> (temporarily) revert to defaults when you suspect a problem is
caused by
> local configuration, it's easier to see what has been locally
modified
> and what hasn't, and especially if the program supports file
inclusion
> (to include then override the default version) you can resolve
more
> updates without needing to do 3-way merges by hand.
>
> The main argument against etc-overrides-lib has been that dpkg can
> automatically give warnings about some of the cases where you may
need
> to update your local configuration. But this ability isn't really
> inherent to the directly-editing case, nor only implementable with
it. I
Currently dpkg allows not only warnings about "some of the cases".
It
always warns user when config file was changed in package and user
edited
installed copy. And provides a a nice way to quickly take a look to
changes, choose which version to use or even start shell for
resolving it
manually. So you just can't miss time when config should be edited
at all.
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
show warnings in these cases, even if the maintainers are aware of
it.
The only workaround would be to make dummy changes to the
configuration
files just to trigger the dpkg warnings, but this would cause other
problems. Thus "can't miss at all" is false.
I don't think it would be a very good idea for a low-level package
manager to screen
for any subtle application changes be in the non-default configuration,
its handling, or otherwise a more general
changes in the application functionality itself. To communicate such
subtle application changes to the users,
there are Changelogs, NEWS files, and upper-level tools like
apt-listchanges. Bonus: BTS + apt-listbugs.
I seriously doubt there is more room left for extra engineering.
--
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/115988c609b2c90f790cffeba8567...@spnet.net
