add conflicts, replaces and breaks section to deprecate docker-compos…

[glours]

…e package in favor of docker-compose-plugin

As Debian docker-compose package still install v1.29.x deprecated version of Compose, we could conflict when a user will try to install the 2 version, so users will be able to either:

• remove an existing docker-compose package before installing docker-compose-plugin
• block install of a docker-compose package if docker-compose-plugin is already installed

https://docker.atlassian.net/browse/ENV-226

[thaJeztah]

/cc @tianon @neersighted

I get the intent, slightly wondering if this is strictly "correct" though, given that the compose-plugin package does not install a docker-compose binary (so no real "conflict"). Also don't know what the general convention is on marking "replaces" for packages we don't own (but I guess there's not a lot of alternatives for that).

I guess we could have a compose-v1-compat package that's optional, and that would install the docker-compose alias (but I guess the intent was still to s/docker-compose/docker compose/

If we're updating this, should we also update the RPM specs accordingly?

[thaJeztah]

One thing we should at least do (without packaging changes), is to update the documentation, and perhaps the get.docker.com script (although I don't think that one currently uninstalls things)

We have sections for each distro that uninstalls packages we know can (soft)conflict; https://docs.docker.com/engine/install/ubuntu/#uninstall-old-versions

[milas]

I guess we could have a compose-v1-compat package that's optional, and that would install the docker-compose alias (but I guess the intent was still to s/docker-compose/docker compose/

Agreed, this seems like the most in-line with packaging and user expectations

I'm not a .deb expert, but Replaces only seems appropriate if we are creating a docker-compose binary, since that would overwrite the v1 binary: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

[thaJeztah]

Yes, we used "replaces" for the docker-buildx-plugin package, as it moved the binary out from the cli package.

I'm not a .deb expert,

debs and rpms are always complicated (and from a "technical" perspective, sometimes more complicated if you need to take different distro versions into account, not all of them supporting all features 😞)

Besides the "technical" perspective, there's tons of conventions and "rules" (some explicit, some implicit), which can make it quite hard to navigate. We want to make the installation as painless as possible, but also must take care not to step on other's toes if there's no need.

[tianon]

A bit late to the party, but I agree that this doesn't seem particularly appropriate unless we install a docker-compose binary that actually conflicts. 😅

If we want to help users convert over to docker compose instead, shouldn't we install a docker-compose that prints warnings to let users know they should swap?

[ndeloof]

Compose v2 should also be installed as docker-compose in user PATH ("standalone" backward compatibility mode)