* Russ Allbery <r...@debian.org> [151005 18:24]: > I'm also in favor. However, this is a very substantial change to Debian > practice, and I'm not sure what process should be used for making this > kind of decision. This wasn't a gap in our specification; rather, the > previous standard was explicitly chosen (by at least some folks). Failure > to install was intentional and believed better since it didn't hide > service failures.
I understand that this was intentional, but it is not the only way to make sure the user (admin) is informed of the failure. It was suggested in the discussion on d-devel that some other notification mechanism could be implemented instead of installation failure. I was thinking about a special dpkg trigger that would be handled internally by dpkg. Packages would, in their postinst, place a file containing non-fatal but important failure information in a directory owned by dpkg. This info would be printed out by dpkg at the end of the run, and would also be passed to front ends that asked. Front ends such as aptitude could ask dpkg for these notifications. If a large installation needed to be split into multiple calls to dpkg, the front end can aggregate the notifications and present them all at the very end, in whatever way is native to the front end. One of the other notifications that I, personally, would like to see this used for is when a configuration file has changes that cannot be handled automatically. Currently you are asked in the middle of the installation; this would not change at all. But it would be nice to have a summary at the end of all the config files that had incompatible changes, regardless of how I answered the dpkg or ucf prompt. > I feel like this would benefit from a broader discussion than just the > Policy list, but I'm not sure how to go about that, or what teams in > particular should weigh in. The discussion started on d-devel; should it be moved back there? The overwhelming majority of opinion seems to be in favor of the change. ...Marvin
