Hi, Roger Shimizu (2020-01-05): > I find this is due to below files were shipped by previous version of > torbrowser-launcher, but not as conffile. > /etc/apparmor.d/local/torbrowser.Tor.tor > /etc/apparmor.d/local/torbrowser.Browser.firefox
Yes. > But now they're shipped with conffile, though in size zero. That's indeed the problem IMO. See below for my reasoning. > So new conffiles complain they don't match with existing ones. Right. > It can be fixed by removing the old files when they match the checksum > of old shipped ones. > The fix will be uploaded soon. I think this can help for files under /etc/apparmor.d/local/ that the package does not install at all anymore (be it via dh-apparmor or as conffiles). This would clean up stuff and that's good :) But I don't think it will help for local/torbrowser.Tor.tor and local/torbrowser.Browser.firefox, which this bug report was initially about. FYI, the very purpose of the files under /etc/apparmor.d/local/ is to be modified by the system administrator, that is, to diverge from what's shipped by packages under /etc/apparmor.d/. The content of these files will, by design, always be: local changes, done manually, and that packages and dpkg should not fiddle with. So, if /etc/apparmor.d/local/* are conffiles, and if the administrator is using this facility, upon upgrades their local changes will necessarily conflict with the (empty) version installed by the package, and dpkg will ask what to do. That would be pretty annoying, since the answer to dpkg's question in this case will always be "keep my local changes, because that's what this file is for after all :)". I hope this clarifies the drawback I see in handling these files as conffiles. Are there advantages in treating them as conffiles, that outweigh this drawback? Cheers, -- intrigeri
