Your message dated Fri, 27 Nov 2020 02:22:26 +0100 with message-id <X8BU0pG/Ei99AE/t...@thunder.hadrons.org> and subject line Re: Bug#971251: dpkg: Accept maintainer's config file if all changes are commented has caused the Debian Bug report #971251, regarding dpkg: Accept maintainer's config file if all changes are commented to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 971251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971251 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: dpkg Version: 1.20.5 Severity: normal X-Debbugs-Cc: hyil...@gmail.com Some packages prompt for whether to accept the package manager's config file or keep the one in the system (like the one shown below). It is quite common (as was the case shown below) that the new config file is in fact just contains some more documentation or commented out lines. I propose that, if all the lines that changed are commented (either from ours or from maintainer), dpkg should *not* prompt for the choice, but instead simply merge the new documentation/commented out available options. Configuration file '/etc/bluetooth/main.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** main.conf (Y/I/N/O/D/Z) [default=N] ? y A possible complication for this is that if the package maintainer or the sysadmin of the system decides to re-arrange the order of the config option lines, then simply merging might further complicate the issue, and result in a convoluted file with the same options showing up at multiple places, which is undesirable even though all of those duplicated lines were commented. But I am sure we can discuss and find a reasonable merge strategy to adopt that would a) allow not having to deal with the choice if everything changed was just comments b) automatic action wouldn't ultimately lead to complex/broken config files if some common editing actions such as swapping chucks of lines were performed -- Package-specific info: System tainted due to merged-usr-via-symlinks. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc6 2.31-3 ii liblzma5 5.2.4-1+b1 ii libselinux1 3.1-2 ii tar 1.30+dfsg-7 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 2.1.10 pn debsig-verify <none> -- no debconf information
--- End Message ---
--- Begin Message ---Hi! On Wed, 2020-09-30 at 02:08:30 +0200, Guillem Jover wrote: > On Mon, 2020-09-28 at 01:51:51 -0400, hyiltiz wrote: > > Package: dpkg > > Version: 1.20.5 > > Severity: normal > > X-Debbugs-Cc: hyil...@gmail.com > > > Some packages prompt for whether to accept the package manager's config > > file or > > keep the one in the system (like the one shown below). It is quite common > > (as > > was the case shown below) that the new config file is in fact just contains > > some > > more documentation or commented out lines. I propose that, if all the lines > > that > > changed are commented (either from ours or from maintainer), dpkg should > > *not* > > prompt for the choice, but instead simply merge the new > > documentation/commented > > out available options. > > > > Configuration file '/etc/bluetooth/main.conf' > > ==> Modified (by you or by a script) since installation. > > ==> Package distributor has shipped an updated version. > > What would you like to do about it ? Your options are: > > Y or I : install the package maintainer's version > > N or O : keep your currently-installed version > > D : show the differences between the versions > > Z : start a shell to examine the situation > > The default action is to keep your current version. > > *** main.conf (Y/I/N/O/D/Z) [default=N] ? y > > > > A possible complication for this is that if the package maintainer or the > > sysadmin of the system decides to re-arrange the order of the config option > > lines, then simply merging might further complicate the issue, and result > > in a > > convoluted file with the same options showing up at multiple places, which > > is > > undesirable even though all of those duplicated lines were commented. But I > > am > > sure we can discuss and find a reasonable merge strategy to adopt that would > > a) allow not having to deal with the choice if everything changed was just > > comments > > b) automatic action wouldn't ultimately lead to complex/broken config files > > if > > some common editing actions such as swapping chucks of lines were > > performed > > As stated, I don't think this report is actionable. The main problem > is that what constitutes a comment or not depends on each individual > file format, which is something dpkg cannot ever assume. This would > need semantic parsing. The automatic merging part would already be > covered by one of the pre-existing bug requests asking for that. > > I guess the only way this could be implemented is if the package > itself provided (or depended on) a configuration file parser > (something like libconfig-model-perl and cme) that could be hooked > into dpkg somehow to perform a semantic merging or similar, but I > don't really see this happening TBH. > > I'm inclined to defer the merging part to the pre-existing reports, > where if such a generic semantic parser and merger was to appear could > be configured by the admin to be used during conffile merge prompts or > similar, and otherwise close this report in a bit. Ok, doing so now, thus closing the report. Thanks, Guillem
--- End Message ---
