Hi! On Sat, 2018-01-27 at 09:46:32 -0500, Jeremy Bicha wrote: > Background > =========
> One of the supported browsers upstream is Google Chrome, which Google > installs to /opt/chrome/ . According to the FHS, that means its > configuration should be stored in /etc/opt/chrome/ . To support Google > Chrome, chrome-gnome-shell must install files to /etc/opt/chrome/ . I don't find the FHS very clear on the /etc/opt topic, TBH. Can for example third-party applications read also /etc/<package> if it's present? That could perhaps be another solution, don't know. > I recently uploaded chrome-gnome-shell 9-2 with Google Chrome support. > It triggers a pipuparts regression (for itself and all its reverse > depends like debian-edu) because when chrome-gnome-shell is removed, > dpkg removes /etc/opt/ since no other package in Debian owns > /etc/opt/. Correct. > base-files creates that directory (in its postinst) because the > Maintainer believes that that directory should be present in new > installs for better FHS compliance but that sysadmins should be > allowed to remove that directory if they like. Yes, to me this rationale make sense, I guess because I think I've even found myself cleaning up these kind of dirs on some of my systems! :) > Suggested Fixes > ============ > > 1. "Google Chrome should not install to /opt/ " IMO, I don't think > this is necessary. Third-party apps should be able to install into /opt, IMO. > 2. "chrome-gnome-shell should not install anything to /etc/opt/ > regardless of whether that means not supporting Google Chrome". IMO > this causes unnecessary harm to Google Chrome users on Debian. Anyway, > if people support this position, then the lintian auto-reject should > be re-established. I think there are two parts to this. One is whether the package should install files there at all. The other is whether it should ship such paths as being owned in the dpkg sense. > 3. "base-files should own /etc/opt/" Rejected by the base-files maintainer. This could be an easy option, but might annoy users that want to get rid of those dirs. > 4. "base-files should introduce a separate, recommended package to own > directories like /etc/opt/". Also rejected by the base-files > maintainer. One additional problem with this approach is that to be able to remove specific dirs, one would need to add then one package per such optional dir? :) > 5. "piuparts could ignore the removal of /etc/opt/" Rejected by the > piuparts maintainer I agree that piuparts should not special case this. > 6. "chrome-gnome-shell could re-create /etc/opt/ in its postrm". Feels > a bit ugly to me, but maybe acceptable if we can't find a better > solution. This might require to preserve sysadmin changes, so if the sysadmin has removed the directory before package installation, it should get removed after package removal too. > 7. How about if dpkg special-case the /etc/opt/ directory and not > remove it when removing a package that ships files there? That's not an option. I'd very much like to keep dpkg be as path neutral as possible by not starting to special case anything which is distribution-specific. I think the ideal solution could imply making it possible to mark pathnames as optional, so that base-files would then mark /opt and friends as such, and the sysadmin could remove them, and those would not get restored on upgrade. Of course the interaction with something like chrome-gnome-shell then becomes a bit tricky, because dpkg then might need to track the state of the dir when the other package appeared, so I'm not sure how that'd play out. For a currently implementable solution, I think you could just ship those files elsewhere, say just /etc. Then install a noawait trigger on /opt/<chrome-whatever> or similar, and when that gets activated create a symlink in /etc/opt/<chrome-whatever> from the maintscript to the place with the actual content. This has the property that it does not pollute the /etc/opt namespace, does not trip on any optional path removal, nor piuparts nor lintian errors, as it will only appear in case the chrome package gets installed. I think leaving the /etc/opt/ directory (but not its symlinked subdir) behind after removing is also probably acceptable here. Would this solve all your problems? Did I miss anything? Thanks, Guillem
