Rudder

Yes, it's a bug. dpkg should deal with this situation. You should use Conflicts: and Replaces:.

Why didn't you use Replaces ?

I wonder if we don't want to repalce all Rudder server packages when forcing rudder-agent to be installed. If I quote Debian Policy Manual (http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces):

Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages. The Replaces control field has these two distinct purposes.

[...]

It is usually an error for a package to contain files which are on the system in another package. However, if the overwriting package declares that it Replaces the one containing the file being overwritten, then dpkg will replace the file from the old package with that from the new. The file will no longer be listed as "owned" by the old package and will be taken over by the new package.

[...]

Second, Replaces allows the packaging system to resolve which package should be removed when there is a conflict (see Conflicting binary packages - Conflicts, Section 7.4). This usage only takes effect when the two packages do conflict, so that the two usages of this field do not interfere with each other.

Jonathan CLARKE wrote:

Nicolas PERRON wrote:

Why didn't you use Replaces ?

I wonder if we don't want to repalce all Rudder server packages when forcing rudder-agent to be installed. If I quote Debian Policy Manual (http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces):

Because this is a fix for 2.3 only, not 2.4. rudder-agent and rudder-cfengine-community still exist as independant packages, but they must not be installed at the same time. Thus, conflicts seems the most appropraite.

This change should not be ported to 2.4 branch, where the logic is different.

Does this make sense?

Yes, it does and I understand.

The fact is that if we want to install rudder-agent, all the packages related to rudder-server-root should be removed and vice-versa. The description of Replaces explains that Replaces allows the packaging system to resolve which package should be removed when there is a conflict which let me think that Replaces should be appropriate for that case.

Then, does Conflict suffice for that case or should we use Replaces, too ? I'm not quite sure if Conflict will suffice.

Conflicts is stronger than Breaks, and is more appropriate in this case, as explained in http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts:

When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than Breaks, which prevents the broken package from being configured while the breaking package is in the "Unpacked" state but allows both packages to be unpacked at the same time. 

The package manager should be able to sort this out without having to list all the server packages, since rudder-server-root requires (directly or indirectly) rudder-cfengine-community, and that conflicts with rudder-agent. So, by extension, rudder-agent conflicts with rudder-server-root.

However, there is no reason why you couldn't install, let's say rudder-inventory-ldap on one node, and have the LDAP database there, on a node that's managed by Rudder, therefore with rudder-agent too. I don't know if that works today, but it should be able to.

Jonathan CLARKE wrote:

Conflicts is stronger than Breaks, and is more appropriate in this case, as explained in http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts:

[...]

The package manager should be able to sort this out without having to list all the server packages, since rudder-server-root requires (directly or indirectly) rudder-cfengine-community, and that conflicts with rudder-agent. So, by extension, rudder-agent conflicts with rudder-server-root.

However, there is no reason why you couldn't install, let's say rudder-inventory-ldap on one node, and have the LDAP database there, on a node that's managed by Rudder, therefore with rudder-agent too. I don't know if that works today, but it should be able to.

Ok, I see clearly now and agree with you.