Hi! 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. Thanks, Guillem
