Hi, On Fri, Aug 16, 2019 at 10:00:37AM +0100, Simon McVittie wrote:
> * non-essential dependencies should be weakened to Recommends or Suggests > to make the overall system more flexible; > * users who change configuration should be able to rely on it not being > lost After thinking about it over the weekend and deleting a much longer draft, I think the relationship should be demoted to Recommends, and the stack fixed to report the error instead of silently losing data if the service is unavailable. The rationale for the demotion is simple: this is a component dependency, not a library dependency. Component dependencies: - refer to interfaces, not implementations (i.e. any component that provides X) - may be circular without any component being aware of that - may resolve to a list of components (e.g. plugins) Because of circularity, hard "Depends:" is out. Applied to the case at hand, it would be absolutely valid to have a GUI application based on Gtk that provides a gconf-settings interface (for example, as part of a session manager), and such a program would generate a Depends cycle. The other two things are not represented well in our package system, and I'm not entirely sure that it would be possible to do that properly, because components are resolved at runtime through several different activation methods, and most of them cannot be statically analyzed. Windows circumvents the problem by pulling most core components into the base system, and generating application manifests during linking that are included as a comment section in the executable, listing component dependencies for static analysis and allowing diagnostics at program start if components are missing rather than unexpected behaviour later. I'd be entirely fine with a program displaying an error dialog at startup if a missing service is unavailable. What I'm not fine with is silently instantiating a dummy component that implements the interface but not the functionality, that's just a bug. Papering over the problem by creating a hard dependency in the package system so the buggy code is never reached is not a solution. Simon
