On 15:07 Wed 08 Feb , Apollon Oikonomopoulos wrote: > On 19:10 Tue 07 Feb , Russ Allbery wrote: > > Alexander Kurtz <alexan...@kurtz.be> writes: > > > > > However, now somebody decided, that it's a good idea to drop the > > > puppet-agent package and move the service file back to the puppet > > > package [1]. This is bad, very, very bad. Here's why:
(In defense of moving things back to puppet from puppet-agent, apart from #826730 and #827867, it was also breaking the upgrade path for people from jessie, since puppet-agent would not be installed automatically for those who had puppet installed.) > > > > I don't think this is the problem. I think the problem is that the > > service is enabled by default. > > > > There's no harm in having everything in one package provided that the > > service defaults to *disabled*, not enabled. My recollection is that this > > is even what the puppet-agent package did, although maybe I'm > > misremembering. > > Sort of, actually in 3.x the service was enabled, but the agent was > disabled in postinst using puppet agent --disable. Nowadays I think it > makes more sense to simply not enable the service by default. > > > But it looks like the default installation logic may have > > been lost with the merge into a single puppet package. > > For the record, this is exactly what happened. Digging a bit further into the issue, the `puppet agent --disable' logic is still there, but it does not currently work for the following reasons: - In an attempt to be as safe as possible, we create the lock file manually (i.e. not via `puppet agent --disable') in *preinst*, with a hardcoded path to the lockfile (/var/lib/puppet/state/agent_disabled.lock). However: - puppet agent's default vardir was changed during the migration to 4.x from /var/lib/puppet to /var/cache/puppet and the agent lockfile path was not updated. Even if it was updated, it still depends on the actual values of vardir and/or agent_disabled_lockfile present in the [main] and [agent] sections of /etc/puppet/puppet.conf. Now, I fixed that by a) adjusting the path in preinst, b) adding an explicit `puppet agent --disable' call in postinst before the debhelper stanzas, which will always do the right thing no matter what the config value for agent_disabled_lockfile is. I also updated the DEP-8 tests to actually check that the lock *puppet agent knows about* is present on installation. This should give the same behavior as puppet 3.7. > > > > > For systemd, I think the fix may be as easy as using --no-enable in a > > dh_systemd_enable override. I'm not sure how this used to be done for > > dh_installinit. For dh_installinit things are unfortunately not that straightforward. The only way I can see for this to work, is to call dh_installinit --no-scripts to prevent dh_ii from modifying the maintainer scripts and then manually add most of the boilerplate code without that single `update-rc.d puppet defaults' call. I find this ugly enough to not prefer it over the `puppet agent --disable' approach.
