Bug #2733: trying to overwrite '/opt/rudder/share/doc/cfengine/ChangeLog', which is also in package rudder-agent 2.3.8-squeeze0 - Rudder - Issue Tracker

Custom queries

8.1 beta
Bugs triage
My TR
Need technical review
Open bugs (all)
Open bugs (UI - UX)
Open UX defects (all)
Opened by users

Actions

Copy link

Bug #2733

closed

trying to overwrite '/opt/rudder/share/doc/cfengine/ChangeLog', which is also in package rudder-agent 2.3.8-squeeze0

Added by Gonéri Le Bouder almost 12 years ago. Updated about 9 years ago.

Status:

Released

Priority:

Assignee:

Nicolas PERRON

Category:

Packaging

Target version:

2.3.9

Pull Request:

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

root@srv00015:/var# dpkg -i ./cache/apt/archives/rudder-cfengine-community_2.3.8-squeeze0_amd64.deb 
(Reading database ... 30999 files and directories currently installed.)
Unpacking rudder-cfengine-community (from .../rudder-cfengine-community_2.3.8-squeeze0_amd64.deb) ...
dpkg: error processing ./cache/apt/archives/rudder-cfengine-community_2.3.8-squeeze0_amd64.deb (--install):
 trying to overwrite '/opt/rudder/share/doc/cfengine/ChangeLog', which is also in package rudder-agent 2.3.8-squeeze0
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 ./cache/apt/archives/rudder-cfengine-community_2.3.8-squeeze0_amd64.deb

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Nicolas PERRON almost 12 years ago

Target version set to 2.3.9

On Rudder 2.3, rudder-agent and rudder-cfengine-community can't be installed on the same machine.
rudder-agent has to be installed on a node and rudder-cfengine-community is part of dependencies of rudder-server-root which has to be installed on a policy server. this is you encountered this bug which is not really a bug.

I think that we could reject this bug.

Actions

Copy link

Updated by Gonéri Le Bouder almost 12 years ago

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

Actions

Copy link

Updated by Jonathan CLARKE over 11 years ago

Status changed from New to In progress
Priority changed from N/A to 1

Gonéri Le Bouder wrote:

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

Of course! This is absolutely right, and I thought it was already the case... but it's not :/

Fixing.

Actions

Copy link

Updated by Jonathan CLARKE over 11 years ago

Status changed from In progress to Pending technical review
% Done changed from 0 to 100

Applied in changeset commit:efe8c56c88e848fa205acfcd8b8c24ddde75575e.

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

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.

Actions

Copy link

Updated by Jonathan CLARKE over 11 years ago

Assignee changed from Jonathan CLARKE to Nicolas PERRON

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?

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

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.

Actions

Copy link

Updated by Jonathan CLARKE over 11 years ago

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.

Actions

Copy link

Updated by Nicolas PERRON over 11 years ago

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.

Actions

Copy link

#11