Remove buggy 10-nouveau.ini creation

[rnewson]

Overview

In an effort to make nouveau easier to use the couchdb-nouveau package would attempt to reconfigure couchdb. However this fails if you install couchdb and couchdb-nouveau at the same time (and doing so is quite normal).

Remove this code. The sysadm can make the single enable = true configuration change themselves.

#154

Testing recommendations

GitHub issue number

Related Pull Requests

Checklist

• Code is written and works correctly;
• Changes are covered by tests;
• Documentation reflects the changes;

[martiell]

An alternative, if you wanted to keep this automated configuration, might be to have nouveau declarePre-Depends: couchdb

This would ensure that the couchdb package had been configured (and the user created) at some point before nouveau is installed:

When a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on package(s) are only in the “Unpacked” or the “Half-Configured” state, provided that they have been configured correctly at some point in the past (and not removed or partially removed since).
https://www.debian.org/doc/debian-policy/ch-relationships.html

Either way is good for me though.

[big-r81]

An alternative, if you wanted to keep this automated configuration, might be to have nouveau declarePre-Depends: couchdb

This would ensure that the couchdb package had been configured (and the user created) at some point before nouveau is installed:

When a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on package(s) are only in the “Unpacked” or the “Half-Configured” state, provided that they have been configured correctly at some point in the past (and not removed or partially removed since).
https://www.debian.org/doc/debian-policy/ch-relationships.html

Either way is good for me though.

Oh nice, I think that’s the solution then when “auto-configure” is the goal like before…

[nickva]

This would ensure that the couchdb package had been configured (and the user created) at some point before nouveau is installed

Would that declare it as a dependency? Which we may not want, since we'd like to be able to install couchdb-nouveau on a separate machine.

[martiell]

Yes, it would. And there's another problem I hadn't thought of: the nouveau postinst would write the configuration file, but couchdb would have already been started from its own postinst script, which Pre-Depends would force to run first. So couchdb would be running with it disabled, until it was manually restarted.

The solution I suggested in #154 was to only try to change the owner of the file if the couchdb user already existed, because the couchdb postinst would then fix up the permissions if it gets installed.

The only other option I could think of (aside from just removing the automated configuration altogether) was to create the couchdb user if it didn't already exist from the nouveau postinst, so the owner could be set correctly. But then the code for creating the couchdb user would then be duplicated across both postinst scripts.

On the other hand, all these feel a bit fragile, so I do see the argument for just removing the automated configuration.

[rnewson]

Unfortunately Pre-Depends is not the solution. We explicitly want to allow couchdb-nouveau to be installed where couchdb is not installed.

I think the only option is to remove the creation of 10-nouveau.ini. Possibly we could create a third package that depends on couchdb and couchdb-nouveau that adds this file, but given the triviality of changing couchdb yourself this seems overkill.

[rnewson]

I updated the PR to print a note instead.