Summary
The Pigsty redis package installs /etc/redis/redis.conf, a file owned by redis-server, but declares neither Conflicts: nor Replaces: for it. When both are present on a node, dpkg refuses the unpack:
trying to overwrite '/etc/redis/redis.conf', which is also in package redis-server 6:7.2.7-1rl1~noble1
Because dpkg aborts the whole run, this is not limited to redis. On one upgrade, a single clashing package left 24 packages unpacked-but-not-configured — including a kernel. A machine in that state that reboots comes up on a half-installed system, which is a far worse outcome than the package conflict itself.
Root cause
Debian Policy §7.6 ("Overwriting files in other packages") requires a package that takes over files from another to declare Replaces:, and Conflicts: when the two cannot be co-installed.
The Pigsty package is monolithic (server + CLI in one deb) while the distribution splits them, so the two packaging layouts cannot coexist — which is fine, but it has to be declared:
$ apt-cache show redis | grep -E '^(Package|Version|Depends|Conflicts|Replaces|Provides):'
Package: redis
Version: 6:7.2.15-4PIGSTY~noble
Depends: adduser, libc6 (>= 2.38), libssl3t64 (>= 3.0.0), libsystemd0
No Conflicts:, no Replaces:, no Provides:. For comparison, the distribution package is a metapackage:
Package: redis
Version: 5:7.0.15-1ubuntu0.24.04.4
Depends: redis-server (<< …), redis-server (>= …)
Note this is not specific to one repo snapshot: apt-cache madison redis shows the Pigsty repo currently serves only 6:7.2.15-4PIGSTY~noble, so a v4.5.0 install gets the same package.
Reproduction
On a Debian/Ubuntu node:
- install
redis-server from the distribution or from the redis.io repo (this also happens when it was pulled in earlier by an unrelated role or by an operator);
- run any
apt-get upgrade that brings in the Pigsty redis package.
The transaction fails at the unpack stage, and every other package in the same run is left unconfigured.
Environment
|
|
| Pigsty |
v4.4.0, and the same package is served for v4.5.0 |
| OS |
Ubuntu 24.04 LTS |
| Pigsty package |
redis 6:7.2.15-4PIGSTY~noble |
| Clashing package |
redis-server 6:7.2.7-1rl1~noble1 (redis.io) — the distribution redis-server owns the same path |
Suggested fix
Declare the relationships in the redis package metadata:
Conflicts: redis-server, redis-tools
Replaces: redis-server, redis-tools
Provides: redis-server, redis-tools
Provides: also lets packages that depend on redis-server remain satisfiable, which the current monolithic package breaks.
With those fields, dpkg replaces the distribution packages cleanly instead of aborting, and an unrelated package upgrade can no longer be taken down by a redis file clash.
Wider note (not part of this report)
Other Pigsty-built packages that shadow distribution ones (haproxy, etcd, grafana, vector) also declare no Conflicts/Replaces. I have not verified whether their file sets actually overlap with the distribution equivalents, so I am not claiming they are affected — only that it may be worth a look while touching the packaging pipeline.
Summary
The Pigsty
redispackage installs/etc/redis/redis.conf, a file owned byredis-server, but declares neitherConflicts:norReplaces:for it. When both are present on a node, dpkg refuses the unpack:Because dpkg aborts the whole run, this is not limited to redis. On one upgrade, a single clashing package left 24 packages unpacked-but-not-configured — including a kernel. A machine in that state that reboots comes up on a half-installed system, which is a far worse outcome than the package conflict itself.
Root cause
Debian Policy §7.6 ("Overwriting files in other packages") requires a package that takes over files from another to declare
Replaces:, andConflicts:when the two cannot be co-installed.The Pigsty package is monolithic (server + CLI in one deb) while the distribution splits them, so the two packaging layouts cannot coexist — which is fine, but it has to be declared:
No
Conflicts:, noReplaces:, noProvides:. For comparison, the distribution package is a metapackage:Note this is not specific to one repo snapshot:
apt-cache madison redisshows the Pigsty repo currently serves only6:7.2.15-4PIGSTY~noble, so a v4.5.0 install gets the same package.Reproduction
On a Debian/Ubuntu node:
redis-serverfrom the distribution or from the redis.io repo (this also happens when it was pulled in earlier by an unrelated role or by an operator);apt-get upgradethat brings in the Pigstyredispackage.The transaction fails at the unpack stage, and every other package in the same run is left unconfigured.
Environment
redis 6:7.2.15-4PIGSTY~nobleredis-server 6:7.2.7-1rl1~noble1(redis.io) — the distributionredis-serverowns the same pathSuggested fix
Declare the relationships in the
redispackage metadata:Provides:also lets packages that depend onredis-serverremain satisfiable, which the current monolithic package breaks.With those fields, dpkg replaces the distribution packages cleanly instead of aborting, and an unrelated package upgrade can no longer be taken down by a redis file clash.
Wider note (not part of this report)
Other Pigsty-built packages that shadow distribution ones (
haproxy,etcd,grafana,vector) also declare noConflicts/Replaces. I have not verified whether their file sets actually overlap with the distribution equivalents, so I am not claiming they are affected — only that it may be worth a look while touching the packaging pipeline.