Re: (newbie) Disruptive LIRC package update.
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
Reply to: