Am Freitag, 23. Dezember 2016, 19:37:33 CET schrieb Vincent Lefevre: > On 2016-12-23 12:10:09 +0100, Marc Haber wrote: > > this is the second time this week that you're filing a duplicate of an > > already existing bug with a severely inflated severity. > > This is not an inflated severity. Under no circumstances, the > installation of a package should make dpkg fail and leave the > packaging system in an inconsistent state (this can block the > correct installation of other packages). Well, actually here > the problem came from the old package from experimental, but > I wasn't aware of this.
The packaging system is not in an inconsistent state: You can always remove the package that fails to upgrade. Or pin it to a certain version to prevent an update. As someone who uses Debian Sid and experimental I expect you to be aware of it. > > While I appreciate your attention on atop, I would really love if > > you could look whether the issue you're reporting already exists. > > I was looking at RC bugs. Which is, as I still think, not the right severity for this bug. Anyhow its always a good idea to look for bugs of all kinds of severity, as: The judgement of someone on severity else may be different than yours. > > This being said, I do agree that #842136 is an issue that we should > > look into, but I don't think it's a release stopper. The issue is > > related to a bug in the version of atop being replaced, that has been > > addressed with atop 2.2.5. I do doubt that this would happen when > > you're upgrading from the ancient version that is currently in unstable. > > > > I would appreciate if you could test that, by installing the version > > from unstable and the upgrading to the current version in > > experimental. That would _really_ help. > > It still fails: > > Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ... > Unpacking atop (2.2.6-1~exp1) over (1.26-2+b1) ... […] > but it doesn't fail on a different machine. I suppose that the problem > comes from the fact that there hasn't been any clean-up after purging > the buggy atop version: I still have the /run/pacct_shadow.d directory > with old files: > > -rw-r--r-- 1 root root 0 2016-12-20 17:19:43 0000000000.paf > -rw-r--r-- 1 root root 7 2016-12-20 17:19:43 current Yes. So to really test this: - Downgrade to atop 1.26 - Reboot, or make sure atopacctd is stopped and remove /run/pacct_shadow.d directory. - Upgrade to 2.26. This should work okay every single time. Unless it doesn´t there is no release critical bug. > But I wonder whether this may still be a problem. I mean that if > atopacctd complains that some file exists, isn't this because it wants > to recreate such a file, in which case the problem could occur again? I think there is. The one I already reported in bug #842136. But it is not release-critical. If you want to add some additional testing, you can try a reinstall of atop 2.26 oder 2.26. If that doesn´t work, there is still an issue with atopacctd not being able to be stopped gracefully. But I do think this is fixed. Or or so, it would be nice if the start unit could clean the directory in case it would still exist, to cover rare corner cases where it might still exist. Now please relax and first have a merry christmas, before panicking about this issue again. Thank you, -- Martin
