If I understand the situation correctly, my subjective opinion is that I don't think a "fix" for this is suitable for an SRU, but I welcome discussion if you disagree.
It's not uncommon to come across a situation where the user configures the system in some non-default way in one configuration file, and something else breaks without the user altering some other configuration file. A couple of unrelated examples of this pattern: 1) A user configures a service to bind to a specific address, but then finds that the service fails to start because this introduces a dependency on having an interface with that address configured first. In this example the service hasn't been written to handle the interface coming up after service start, which would be the ideal solution to the problem. In the meantime, the user needs to also configure the init system to order the service start after the interface configuration. 2) A user configures a service to use a non-standard filesystem location, but then finds that AppArmor blocks access to that location. The user needs to also adjust the AppArmor profile to permit access to that location. So here we have (I think): 3) A user disables IPv6. The user also needs to adjust the nginx configuration to not attempt to bind to IPv6 addresses. In all of these cases, I agree that it would be nice if the appropriate thing could automatically detect the other configuration change and adjust itself accordingly by default. Doing this would certainly be a valuable usability improvement. However, I don't think these are bugs as such; this is expected behaviour albeit that the expected behaviour could be improved upon. While we might be able to make individual enhancements, in the general case it's clearly impossible to infer every possible necessary adjustment automatically. In the meantime, a user who adjusts away from default configuration in one place is expected to adjust other dependent configuration to match. My conclusion is that this is a valid Wishlist-level bug in that in this specific case it would be nice if the default nginx configuration would continue to work without needing adjustment to match the global IPv6 disablement. However, for the reasons above I don't think an SRU is warranted, since the current behaviour is expected behaviour and doesn't prevent the user from achieving what they want. The currently correct way of handling this is to adjust nginx configuration, which is possible without needing any changes to the existing packaging. I appreciate the efforts to make this experience better for users. That should take effect in future releases (but not change behaviour in existing stable releases). I therefore propose "Won't Fix" for the Ubuntu stable release bug tasks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1743592 Title: NGINX fails to start/install/upgrade if IPv6 is completely disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
