Lorenzo wrote: > Yes you are right, this is the issue: I see from you output > that you have a hook or some setting that automatically purge > packages after removal. Am I correct?
No, purging packages is a normal part of using Debian. It's not a special hook, it's just a completely normal administrator activity. > The default setting in apt is that packages are not purged after > removal; That's not exactly accurate. There are a lot ways to manage packages, apt is one, I happen to use aptitude most of the time, but this isn't a setting we're talking about, it's an entirely normal action. Purging packages is how you keep your system free from unused conf files. > your sequence is particularly unfortunate here because runit-run and > runit-systemd share the same conffiles, so you end up with runit-run > in a weird state like installed, configured but purged at the same > time, de facto overriding the "enable by default" setting of > runit-run. > > This bug exists but only under a particular configuration of apt; > changing the name of the service so that the purge of runit-systemd > does not affect runit-run could be a fix, but then some other user > may popup and complain that i broke their setup with an unnecessary > change.. No, it's not a particular configuration of apt. It's how package management on Debian works. If you're going to maintain packages, you have to understand these mechanics intimately or you'll wind up causing no end of problems for users. > I think I will leave this bug open for a while (for reference to > other users that may run into the same issue) but unfixed, as I > don't have an idea for a fix that does not have the potential to > break other people's stuff. > > I'm still open to suggestions and further discussion You probably should get help from the maintainer community, and they can explain the best approach to refactoring these packages so the migration is smooth. As it stands, when you introduced runit-run you created this problem for every user of runit-systemd. The only way to avoid the problem is to avoid having the runit-systemd.postrm script from runit-systemd <= 2.1.2-36 run after runit-run is installed. You could introduce a new version of a more-or-less empty transition runit-systemd package that runit-run depends on, to ensure a version of the runit-systemd.postrm script that doesn't disable the unit exists prior to purge, it's just ugly becuase sysvinit users would be forced into installing a package with "systemd" in the name (even though it shouldn't depend on systemd) which is going to cause confusion. The maintainer community will hopefully have better advice that results in a cleaner transition. -- Jamie Heilman http://audible.transient.net/~jamie/
