On 10/11/15 14:49, Andrew Shadura wrote: > On 10/11/15 13:39, Alec Leamas wrote: >> On 10/11/15 13:26, Andrew Shadura wrote: >> >>>> I think migrating from old config to a new config in a postinst is okay >>>> as long as you keep the old config and complain to the user that a >>>> manual verification may be needed. >>>> >>>> As least ifupdown did that a couple of times, and nobody complained :) >> The thing is that dpkg seems to complain. The manual [1] states that: >> >> "Note that a package should not modify a dpkg-handled conffile in its >> maintainer scripts. Doing this will lead to dpkg giving the user >> confusing and possibly dangerous options for conffile update when the >> package is upgraded." >> >> In this case, the options presented by dpkg would indeed be both >> confusing and dangerous. >> >> Seemingly, this is also the root cause to the upgrade path bug #655969 [2]. >> >> Or, did the ifupdown maintainers found a way around the manual, dpkg and >> piuparts checks? > > I think you can try to do it systemd way: keep the default configuration > in /usr/lib, and leave /etc for local user configuration which overrides > the default config. > > Not sure how good is this idea, I hope others can comment on this.
As I said earlier, I don't think this is a good idea - there are more comments on why in this thread. However, it touches one possible route: to store the original vendor files separately and create the actually used config files in postinst. In the lirc_options.conf case this could be installing lirc_options.conf as lirc_options.conf.dist. And then creating lirc_options.conf in postinstall. This means that lirc_options.conf is not part of the package, the E.2 case in the manual [1]. Other /etc/lirc/*.conf files could be handled the same way. It's a bit clumsy, but consistent. piuparts still complains, but the culprits are files not owned by the package so we could ignore this (?) I still prefer the manual route where users runs the upgrade script and verifies the results. But technically, this seems to work - I have made some test shots. Thoughts? --alec [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html