Re: Config upgrade with cme (was Re: (newbie) Disruptive LIRC package update.)
Le 12/11/2015 18:36, Dominique Dumont a écrit : > Hello Vincent > > On Wednesday 11 November 2015 17:11:13 Vincent Danjean wrote: >> I looked at [2] (cme seems really powerfull to offer automatic >> upgrade/merge of config files). I've two questions after reading the wiki: >> >> 1) I vaguely recall recommendations/requirement that a package >> should/must not depends on a file in /usr/share/doc/pkg for its >> work (as this directory can be removed to get some place). >> The wiki says that "[LCDd.conf] is now delivered in >> /usr/share/doc/lcdproc and not in /etc/". Won't /usr/share/lcdproc >> be a better place ? > > cme does not use original LCDd.conf when upgrading user's configuration. > Original LCDd.conf is placed in /usr/share/doc so that user wanting to bail > out of automatic upgrade has a reference file to help him do manual edition > of > /etc/LCDd.conf. Ok. I was thinking wrong. I was under the impression that cme used the original LCDd.conf. >> 2) "user will be asked *once* by debconf whether to use automatic >> configuration upgrades or not. * no further question will be asked >> (no ucf style questions)." >> Why not preparing (unconditionally) the new version of the configuration >> file with cmd [cme] and then use ucf to install it in /etc? That way, >> the user would be prompted only when he has done new changes since >> the last package upgrade (and the "install maintainer version" prompt >> would then install the cme built config file) > > Err, I don't really understand the problem you're trying to solve here... > > Are you suggesting to prompt user to approve that his "new changes since > the last package upgrade" are propagated to the new version of the > configuration file ?? Yes. I'm always a bit relunctant to not check that the merge of my modif and upstream modif works well. It is probably because I only used line-based merge methods (merge3, ...) that does not know anything about the structure and the semantic of the file. cme is probably way better here. I really need to try it. Thanks for your answers Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: Config upgrade with cme (was Re: (newbie) Disruptive LIRC package update.)
On Thursday 12 November 2015 23:14:16 you wrote: > Ok. I was thinking wrong. I was under the impression that cme used > the original LCDd.conf. The wiki page is not clear enough then. I'll modify it. > Yes. I'm always a bit relunctant to not check that the merge of my > modif and upstream modif works well. It is probably because I only > used line-based merge methods (merge3, ...) that does not know > anything about the structure and the semantic of the file. cme is > probably way better here. I really need to try it. Then, feedback and suggestions will be welcome :-) All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: (newbie) Disruptive LIRC package update.
On Wed, Nov 11, 2015 at 04:52:06PM +0100, Dominique Dumont wrote: > A file delivered by a package in /etc automatically becomes a conffiles. If you use debhelper. (not saying you shouldn't, but hey, sometimes being pedantic is good) -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Config upgrade with cme (was Re: (newbie) Disruptive LIRC package update.)
Hello Vincent On Wednesday 11 November 2015 17:11:13 Vincent Danjean wrote: > I looked at [2] (cme seems really powerfull to offer automatic > upgrade/merge of config files). I've two questions after reading the wiki: > > 1) I vaguely recall recommendations/requirement that a package > should/must not depends on a file in /usr/share/doc/pkg for its > work (as this directory can be removed to get some place). > The wiki says that "[LCDd.conf] is now delivered in > /usr/share/doc/lcdproc and not in /etc/". Won't /usr/share/lcdproc > be a better place ? cme does not use original LCDd.conf when upgrading user's configuration. Original LCDd.conf is placed in /usr/share/doc so that user wanting to bail out of automatic upgrade has a reference file to help him do manual edition of /etc/LCDd.conf. > 2) "user will be asked *once* by debconf whether to use automatic > configuration upgrades or not. * no further question will be asked > (no ucf style questions)." > Why not preparing (unconditionally) the new version of the configuration > file with cmd [cme] and then use ucf to install it in /etc? That way, > the user would be prompted only when he has done new changes since > the last package upgrade (and the "install maintainer version" prompt > would then install the cme built config file) Err, I don't really understand the problem you're trying to solve here... Are you suggesting to prompt user to approve that his "new changes since the last package upgrade" are propagated to the new version of the configuration file ?? All the best. > Regards, > Vincent > > > [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html > > [2] https://wiki.debian.org/PackageConfigUpgrade#Apply_configuration_upgrade_using_an_existing_model:_lcdproc_example > >[3] http://manpages.org/dh_cme_upgrade > > > > (*) it took me a while to understand the difference :o) -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
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
Re: (newbie) Disruptive LIRC package update.
Le mardi 10 novembre 2015, 12:42:21 12:42:21 Alec Leamas a écrit : > Also: updating the new config files, systemd or /etc/lirc/*, in > maintainer scripts is not allowed [1] (?) Not exactly. You're confusing "configuration file" and "conffile" (*). Both can exists in /etc/. The latter is handled by dpkg. A file delivered by a package in /etc automatically becomes a conffiles. In this case, restriction mentioned in [1] apply. On the other hand, if your post-inst script creates a configuration file in /etc, this file is not handled by dpkg and is not a conffile. That's what I did for to be able to upgrade automatically lcdproc configuration [2] by cme in a postinstall script with dh_cme_upgrade [3] > Which means that what I could and should do is: > - Make a script which can handle update in most cases. > - Make manual update documentation. > - Have prominent notices in debian/NEWS about required disruptive > configuration update with links to both tool and update docs. This is allowed by [1] provided the migration scripts are run by user and not by post-install scripts. > My newbie skills cannot find anything better. You're doing very well. :-) All the best [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html [2] https://wiki.debian.org/PackageConfigUpgrade#Apply_configuration_upgrade_using_an_existing_model:_lcdproc_example [3] http://manpages.org/dh_cme_upgrade (*) it took me a while to understand the difference :o)
Re: (newbie) Disruptive LIRC package update.
Hi, Le 11/11/2015 16:52, Dominique Dumont a écrit : > On the other hand, if your post-inst script creates a configuration file in > /etc, this file is not handled by dpkg and is not a conffile. > > That's what I did for to be able to upgrade automatically lcdproc > configuration [2] by cme in a postinstall script with dh_cme_upgrade [3] I looked at [2] (cme seems really powerfull to offer automatic upgrade/merge of config files). I've two questions after reading the wiki: 1) I vaguely recall recommendations/requirement that a package should/must not depends on a file in /usr/share/doc/pkg for its work (as this directory can be removed to get some place). The wiki says that "[LCDd.conf] is now delivered in /usr/share/doc/lcdproc and not in /etc/". Won't /usr/share/lcdproc be a better place ? 2) "user will be asked *once* by debconf whether to use automatic configuration upgrades or not. * no further question will be asked (no ucf style questions)." Why not preparing (unconditionally) the new version of the configuration file with cmd and then use ucf to install it in /etc? That way, the user would be prompted only when he has done new changes since the last package upgrade (and the "install maintainer version" prompt would then install the cme built config file) Regards, Vincent > [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html > [2] > https://wiki.debian.org/PackageConfigUpgrade#Apply_configuration_upgrade_using_an_existing_model:_lcdproc_example > [3] http://manpages.org/dh_cme_upgrade > > (*) it took me a while to understand the difference :o) > -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: (newbie) Disruptive LIRC package update.
Le 11/11/2015 15:31, Alec Leamas a écrit : > On 11/11/15 15:17, Vincent Danjean wrote: >> Le 11/11/2015 10:37, Alec Leamas a écrit : >>> However, it touches one possible route: to store the original vendor >>> files separately and create the actually used config files in postinst. >> ucf has been written for this. Do not reinvent the wheel, use ucf. >> The doc even provides info about how to move from a dpkg conffile >> to a configuration file managed by ucf. > > Indeed! Thanks for the hint, this seems to be the way if going for an > automated update. Feel free to ping me if you want a review on this part of the packaging before uploading. I'm not sure I won't miss something but I used ucf in several of my packages. Regards, Vincent > > Cheers! > > --alec > -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: (newbie) Disruptive LIRC package update.
Le 11/11/2015 10:37, Alec Leamas a écrit : > However, it touches one possible route: to store the original vendor > files separately and create the actually used config files in postinst. ucf has been written for this. Do not reinvent the wheel, use ucf. The doc even provides info about how to move from a dpkg conffile to a configuration file managed by ucf. You will get for free all the mechanisms required to prompt the user on upgrade if required. Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: (newbie) Disruptive LIRC package update.
On 11/11/15 15:17, Vincent Danjean wrote: Le 11/11/2015 10:37, Alec Leamas a écrit : However, it touches one possible route: to store the original vendor files separately and create the actually used config files in postinst. ucf has been written for this. Do not reinvent the wheel, use ucf. The doc even provides info about how to move from a dpkg conffile to a configuration file managed by ucf. Indeed! Thanks for the hint, this seems to be the way if going for an automated update. Cheers! --alec
Re: (newbie) Disruptive LIRC package update.
On 09/11/15 17:44, Alec Leamas wrote: > On 08/11/15 19:28, Dominique Dumont wrote: >> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote: > So, this is a change, yes. But in the long run, wouldn't we be better > off by sticking to upstream's way of doing it instead of running a > separate Debian race? Yes, I have both hats. But still... Also: updating the new config files, systemd or /etc/lirc/*, in maintainer scripts is not allowed [1] (?) Which means that what I could and should do is: - Make a script which can handle update in most cases. - Make manual update documentation. - Have prominent notices in debian/NEWS about required disruptive configuration update with links to both tool and update docs. My newbie skills cannot find anything better. If there is no more input, I will return to this thread once there is a RFS available. Cheers! --alec [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html --alec
Re: (newbie) Disruptive LIRC package update.
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? Cheers! --alec [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655969
Re: (newbie) Disruptive LIRC package update.
On 10/11/15 12:42, Alec Leamas wrote: > On 09/11/15 17:44, Alec Leamas wrote: >> > On 08/11/15 19:28, Dominique Dumont wrote: >>> >> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote: >> > So, this is a change, yes. But in the long run, wouldn't we be better >> > off by sticking to upstream's way of doing it instead of running a >> > separate Debian race? Yes, I have both hats. But still... > Also: updating the new config files, systemd or /etc/lirc/*, in > maintainer scripts is not allowed [1] (?) 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 :) -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
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 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. Wouldn't this effectively be the package climbing on the sysadmin's feet? As I understand it, vendor configuration (and in this context, debian is vendor, right?) goes into /usr/lib/systemd whereas the local sysadmin rules over /etc/systemd? Anyway, it turns out that the systemd files are really not updated. The configuration lives in lirc_options.conf, some other /etc/lirc/*.conf files + the very fact that certain systemd units are enabled/started or not. And starting fresh systemd services behind the back of local sysadmin - is this a nice thing to do? Cheers! --alec
Re: (newbie) Disruptive LIRC package update.
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. -- Cheers, Andrew
Re: (newbie) Disruptive LIRC package update.
On 08/11/15 19:28, Dominique Dumont wrote: > On Sunday 08 November 2015 15:19:30 Alec Leamas wrote: >> Some tooling to build the new configuration from the old will indeed be >> required. This is actually some work - it includes a complete lircd >> command line parser with ~18 options. But it's certainly doable. > > Good to know > >> The real reason why I think some user intervention is if not necessary >> at least desirable is the semantic gap between the old and new >> configuration. In particular, the current config enables the 'lirc' >> service which then starts up to four different server processes. The new >> config is actually up to four different systemd services which need to >> be handled separately by the user. > > If I rephrase, with the current setup, 'service lirc start' starts 4 daemon > processes. > > Which means the user only has to type one command to start and stop all of > them. > > With the new setup. the user will have to deal with 4 systemd services (one > per daemon) and will have to run 4 systemctl commands to start or stop lirc. > > Is that correct ? Yes. But "user only has to type one command to start and stop all of them" is sort of misleading. The four services are actually three (my bad): - lircd (always used) - lircmd (seldom used to let the remote emulate a mouse) - irexec (sometimes used to let a remote runn random system commands) Each of these services requires specific setup. What the current lirc script does is to look at the setup and then decides to start a service or not. E. g., if the irexec.conf file exists and is "good" according to some conditions AND the START_IREXEC configuration variable is not false, then 'service lirc restart' starts irexec Now, is this simple? Simpler than, if you want to configure irexec, create the configuration file and run systemctl start irexec.service? I don't see it that way. And, not to forget, if I should stick to this convention there would be a need of much more downstream documentation, since this is different from upstream and all other distros which have packaged lirc beyond 0.9.0. So, this is a change, yes. But in the long run, wouldn't we be better off by sticking to upstream's way of doing it instead of running a separate Debian race? Yes, I have both hats. But still... Cheers! --alec
Re: (newbie) Disruptive LIRC package update.
On 07/11/15 10:05, Dominique Dumont wrote: > On Friday 06 November 2015 18:48:29 Alec Leamas wrote: >> So, an upgrade will not support hardware.conf. Which basically breaks >> each and every installation. While we could (i. e., should) provide docs >> and perhaps some tooling to ease the process, > > Well, you can provide a tools to upgrade from hardware.conf to the new > configuration files (systemd based) using > > https://wiki.debian.org/PackageConfigUpgrade > > Since hardware.conf is quite small, the creation of the model shouldn't take > long. Creating the code to read hardware,conf is easy, creating the code to > write files using systemd syntax shouldn't take long. I could help you there > if > you don't know Perl. > >> I think some kind of >> manual intervention is unavoidable. > > Why ? because of the format change ? or does the user have to provide more > information ? (the latter would more or less break the upgrade described > above) Hi1! Some tooling to build the new configuration from the old will indeed be required. This is actually some work - it includes a complete lircd command line parser with ~18 options. Bit it's certainly doable. The real reason why I think some user intervention is if not necessary at least desirable is the semantic gap between the old and new configuration. In particular, the current config enables the 'lirc' service which then starts up to four different server processes. The new config is actually up to four different systemd services which need to be handled separately by the user. Sure, it's possible to enable and start systemd services from the existing configuration. But won't this be rather confusing for the user? --alec
Re: (newbie) Disruptive LIRC package update.
On Sunday 08 November 2015 15:19:30 Alec Leamas wrote: > Some tooling to build the new configuration from the old will indeed be > required. This is actually some work - it includes a complete lircd > command line parser with ~18 options. Bit it's certainly doable. Good to know > The real reason why I think some user intervention is if not necessary > at least desirable is the semantic gap between the old and new > configuration. In particular, the current config enables the 'lirc' > service which then starts up to four different server processes. The new > config is actually up to four different systemd services which need to > be handled separately by the user. If I rephrase, with the current setup, 'service lirc start' starts 4 daemon processes. Which means the user only has to type one command to start and stop all of them. With the new setup. the user will have to deal with 4 systemd services (one per daemon) and will have to run 4 systemctl commands to start or stop lirc. Is that correct ? > Sure, it's possible to enable and start systemd services from the > existing configuration. But won't this be rather confusing for the user? As long as lirc is up and running after package upgrade, I think user won't care. I guess that user may be confused when investigating issues with lirc. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: (newbie) Disruptive LIRC package update.
Le dimanche 8 novembre 2015, 19:28:38 Dominique Dumont a écrit : > > If I rephrase, with the current setup, 'service lirc start' starts 4 daemon > processes. > > Which means the user only has to type one command to start and stop all of > them. > > With the new setup. the user will have to deal with 4 systemd services (one > per daemon) and will have to run 4 systemctl commands to start or stop lirc. > > Is that correct ? Or a systemd target can be defined to pull in these 4 services at once. Alexandre
Re: (newbie) Disruptive LIRC package update.
On Friday 06 November 2015 18:48:29 Alec Leamas wrote: > So, an upgrade will not support hardware.conf. Which basically breaks > each and every installation. While we could (i. e., should) provide docs > and perhaps some tooling to ease the process, Well, you can provide a tools to upgrade from hardware.conf to the new configuration files (systemd based) using https://wiki.debian.org/PackageConfigUpgrade Since hardware.conf is quite small, the creation of the model shouldn't take long. Creating the code to read hardware,conf is easy, creating the code to write files using systemd syntax shouldn't take long. I could help you there if you don't know Perl. > I think some kind of > manual intervention is unavoidable. Why ? because of the format change ? or does the user have to provide more information ? (the latter would more or less break the upgrade described above) All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: (newbie) Disruptive LIRC package update.
Hi Alec, Quoting Alec Leamas (2015-11-06 18:48:29) > I am in the process on creating a new lirc packaging. The core reason > is that current debian version is stalled at 0.9.0 as of 2011 whereas > the upstream version is 0.9.3, with 0.9.4 under way. My plan is to try > to package 0.9.4. > > Besides the more practical issues here is a big configuration trouble. > Up to 0.9.0, lirc has been configured using a file hardware.conf. This > is a debianism which never has been upstreamed. This file just isn't > compatible with modern lirc which partly relies on the systemd setup, > partly on a file called lirc_options.conf. > > So, an upgrade will not support hardware.conf. Which basically breaks > each and every installation. While we could (i. e., should) provide > docs and perhaps some tooling to ease the process, I think some kind > of manual intervention is unavoidable. > > Now, I'm new to the Debian community. What is the policy w r t this > kind of upgrades? As hinted on debian-mentors, I'm seeking advice in > this list. Document how to migrate in README.Debian file, and add a NEWS file with an entry to briefly mentioning the need for migration and pointing to the README file where the details are. NB! the exact naming of the NEWS file is important, and the timestamp of the entry in that file must match the timestamp of your upcoming changelog entry (I'v gotten those details wrong myself numerous times): Test the final package works by installing apt-listchanges, and then when you install the new package it should show the NEWS entry _before_ the package is installed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
