[Aptitude-devel] Bug#806770: Bug#806770: aptitude: Command parameter to restore /etc/ configuration files easily

[Manuel A. Fernandez Montecelo]

Hi,

2015-12-01 16:40 Axel Beckert:
>Control: block -1 by 32877
>
>Hi,
>
>Manuel A. Fernandez Montecelo wrote:
>> >It would be satisfying if that command would have 1 parameter only instead of
>> >long command not easy to remember:
>> >sudo apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall
>> ><package-name>

BTW, the example is with apt-get, so I am not 100% sure if the bug
report is intended for apt or aptitude.

David, can you please clarify?


>> Isn't this more or less the same?
>>
>>  aptitude purge ${pkg}; aptitude install ${pkg}
>
>No. This forces all reverse dependencies to be removed. That's
>definitely not what you want.

It depends on the specific case, but in general it looks cleaner to me
to purge and install again (and to do the ancillary tasks like restarts
in proper order) than to change config under the hood.

That is, given that the functionality as described existed in aptitude,
I personally would probably choose to do purge && install anyway.

By default, even if ${pkg} is purged, rdeps are only removed (== config
file preserved), and the lead package would be installed with pristine
config (as desired) and (again with the defaults) the action should pull
in all deps/recommendations again, and these would work with their old
config, which was not removed.


With reinstalling conffiles of a single package, if the rdeps really
depend on the package and need to do an operation while things are
broken and being reinstalled, they can malfunction or even in extreme
cases break the system.

For a very gross example, if they depend on config variables from that
package and they do e.g. a:

  source /etc/default/file-from-package-reinstalled
  ...
  rm -rf $SOMEVAR_TMP/*

and $SOMEVAR_TMP is empty because the files were being reinstalled at
the time or the old config had a typo in the var name...

Similar odd cases, but less dramatic and more subtle breakages, can
happen if a program depends on e.g. ca-certificates and that package
exporting variables, or config files or symlinks of where their dirs
with certificates are installed; or ${language}-packages or compiled
e-lisp can go/remain in the wrong place until the rdepends are
themselves reinstalled.

In short, anything that was done while the packaged depended upon had
wrong configuration can have consequences in the dependencies.  I think
that the consequences have more chances to linger on or persist
indefinitely if the rdeps themselves are not reinstalled.  In other
words, the programs relying on bad config from other package can
malfunction until restarted, reconfigured or reinstalled, after the
config of the package that they depend upon is restored and working
again.


Maybe I am mistaken and this can be achieved in a clear and safe way
with the cooperation of all packages involved, or it's not very
different really from the mechanisms for upgrading packages (??) and it
should be safe and I am worrying to much.

But in general, it is under this light that this feature request looks
to me as providing ways for people to shoot themselves in the foot more
easily (or, *too* easily) and efficiently -- so I don't know if it's a
good idea.

At least with purge&install people are made aware that there are going
to be hiccups in services, and possibly breakage, so a clear indication
to "tread with care", rather than just "reset this package's config"
which might sound safer.


>IMHO the clean way to get this kind of feature set is when dpkg does
>not only remember the default hashsum of all conffiles, but the whole
>contents of the conffile. See https://bugs.debian.org/32877 ("dpkg:
>Cleverer conffile merge") for that discussion.

I am not sure if this bug is entirely related, since the original
submitter seems to want to wipe the existing config files altogether and
restore the original ones shipping with the package because the existing
ones are wrong.

So if I got things right, fixing that bug report can do exactly what he
doesn't want.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>