dpkg-divert breaks nginx installation

I'm going to take a wild guess that the issue is because vivid's nginx-common.postinst has this line:

invoke-rc.d nginx start || exit $?

Which will make postinst fail if nginx fails to start for the first time.

15.04:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/nginx/vivid/view/head:/debian/nginx-core.postinst

14.04 did not have this behaviour:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/nginx/trusty/view/head:/debian/nginx-common.postinst

Benjamin,

Thanks for the post here. However, there's no debug information available here, really, to poke at things. One huge difference from 14.04 and 15.04 is systemd, can you include some debug information (such as the output of `systemctl -l status nginx.service` and `journalctl -xe`) so we can see why exactly nginx died off?

@Thomas Ward
Firstly, a correction: 14.04 also has the issue, I was looking at the wrong file ( http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/nginx/trusty/view/head:/debian/nginx-core.postinst is correct )

Let me try to summarize the issue a little better:

You have a package, johnny-dep, and it depends on nginx
johnny-dep has `dpkg-divert /etc/nginx/nginx.conf` in its preinst script

When we install johnny-dep, nginx will also be installed. What happens is this:

1) johnny-dep adds the diversion, now there is no file /etc/nginx/nginx.conf
2) nginx installs, but during its configuration it exits because there's no /etc/nginx/nginx.conf

--

Meanwhile, I found this work-around/solution:

I listed nginx in "Pre-Depends" in my debian/control, thus nginx will run its postinst script before johnny-dep's preinst script is run.

If this is enough to consider this a non-bug, that's acceptable. Maybe I disagree a little bit that nginx doesn't work conventionally with a diversion of its configuration file, but on the other hand, it's not very severe.

Just read this:

> > Conceptually, a diverting package actually pre-depends on the package
> > being diverted.

Furthermore:

> Current behaviour of dpkg-divert is not an excuse to retain it, IMHO.
> Conceptually, dpkg-divert in preinst scripts is just wrong.

From this discussion:

https://lists.debian.org/debian-embedded/2010/04/msg00025.html

I don't know what to make of all this :) I guess there are many discussions about how to do things, but the Debian Wiki suggests to put things in preinst, which then makes everything diversion a "conceptual pre-depends".

https://wiki.debian.org/Adding%20and%20removing%20diversions

AIUI, it isn't appropriate for a package to modify another package's behaviour from under its feet in this way. Debian Policy Appendix G (not formally policy I don't think) says: "Do not attempt to divert a conffile, as dpkg does not handle it well.". Though https://wiki.debian.org/ConfigPackages does talk about this method.

Another cleaner approach would be to have your johnny-dep package provide its own configuration file and init script somewhere else, and then depend on a package that provides the nginx binaries but no configuration. I don't know if nginx provides such packages currently, but if changes are required there I'd recommend that they be done in Debian rather than carrying an Ubuntu delta.

Up to Thomas though.

Regarding the discussion about dpkg-divert: It's inevitable -- I wanna change something in nginx.conf that's not possible to change elsewhere because /etc/nginx/conf.d is only loaded in the http { ... } segment:

2015/11/11 22:29:32 [emerg] 15102#0: "worker_processes" directive is not allowed here in /etc/nginx/conf.d/test.conf:1

I see the point of avoiding it, but it demands changes in the original package to allow other packages to avoid modifying its configuration files.. but it's almost the same problem with user-defined modifications. There should always be room for both these cases.

Agreed, no need to patch this in Ubuntu. Should be done in Debian, which I can see would have the same problem.

But it seems it will be hard to find consensus about whether such things should be addressed or not!

I'm going to take the following actions on this bug, and the Server Team is OK'd to say otherwise, since I'm slightly sleep deprived.

> Agreed, no need to patch this in Ubuntu. Should be done in Debian, which I can see would have the same problem. -- Benjamin Bach, November 11, 2015, Comment 7

Given that there is no need to patch this in Ubuntu, and this should be done in Debian, I am going to "Won't Fix" this bug here, and suggest that you file a bug against the Debian package and have them fix it there. If they decide to make changes, they'll make it in when I next merge the package from Debian Unstable. This link is Debian's "How to File a Bug" page and can help you get started with filing a bug in Debian against the nginx package for this issue (since it should really be fixed there): https://www.debian.org/Bugs/Reporting

> AIUI, it isn't appropriate for a package to modify another package's behaviour from under its feet in this way. Debian Policy Appendix G (not formally policy I don't think) says: "Do not attempt to divert a conffile, as dpkg does not handle it well.". -- Robie Basak, November 11, 2015, Comment #6

Idle hands are the Devil's Playthings, so I went and poked the Debian IRC channels. #debian-mentors also refers to 10.7.4 of the Debian packaging policy - https://www.debian.org/doc/debian-policy/ch-files.html - which states the same thing in its contents:

I'm just going to quote it here for simplicity, with a later point below of what spots I'm specifically referring to:

---

10.7.4 Sharing configuration files

If two or more packages use the same configuration file and it is reasonable for both to be installed at the same time, one of these packages must be defined as owner of the configuration file, i.e., it will be the package which handles that file as a configuration file. Other packages that use the configuration file must depend on the owning package if they require the configuration file to operate. If the other package will use the configuration file if present, but is capable of operating without it, no dependency need be declared.

If it is desirable for two or more related packages to share a configuration file and for all of the related packages to be able to modify that configuration file, then the following should be done:

One of the related packages (the "owning" package) will manage the configuration file with maintainer scripts as described in the previous section.

The owning package should also provide a program that the other packages may use to modify the configuration file.

The related packages must use the provided program to make any desired modifications to the configuration file. They should either depend on the core package to guarantee that the configuration modifier program is available or accept gracefully that they cannot modify the configuration file if it is not. (This is in addition to the fact that the configuration file may not even be present in the latter scenario.)

Sometimes it's appropriate to create a new package which provides the basic infrastructure for the other packages and which manages the shared configuration files. (The sgml-base package is a good example.)

If t...

Won't fix +1

Pre-Depends is really an easy work-around!!

I see problems with dpkg-divert, but I also see work-arounds and room for discussions and improvements of individual packages. I don't think we need to say that "dpkg-divert" should be discouraged because of debian policy, nor do I see a need that we should require changes to packages that are functional because of diversions of configuration files by some other package.