Hi!
On Mon, 2023-05-08 at 18:44:57 +0900, Simon Richter wrote:
There are a few very unlikely corner cases where I'm unsure what would be expected of dpkg:
So in general diversions are off-band redirections, that can live
independently to the package lifetime. But they are taken into account
when deciding whether to disappear a package iff they are involved in
a contended pathname. This is part of the src/main/archives.c:filesavespackage() function.
I've now fixed a test case involving disappearing packages, and added
a couple more tests covering these and other cases, and pushed them.
Thanks for prompting this! :)
1. a package not providing a diverted file, and then disappearing
pkg-a contains /x and registers a diversion /y -> z.
pkg-b contains /y
pkg-c Replaces pkg-a and contains /x
Installing pkg-c overwrites the last file in pkg-a. Should pkg-a disappear
at this point, or does the diversion count?
Assuming that pkg-a does not contain /y, then pkg-a will disappear,
because it does not get saved as there's no contended pathname
involved. (If pkg-a shipped /y then it would not get disappeared.)
2. like 1, but no one else provided the diverted file either
The same scenario, but only pkg-a and pkg-c are installed, so /y does not even exist and is therefore not redirected to /z. Does pkg-a disappear?
As with 1 pkg-a should disappear, because the diversion is not
contended.
3. a diversion target is replaced
pkg-a contains /x and registers a diversion /x -> y
pkg-b contains /x and is diverted to /y
pkg-c Replaces pkg-b and contains /y
Is that allowed? Does pkg-b disappear?
This will fail when trying to overwrite /y as that's a diversion
conflict (unless --force-overwrite-diverted is used), so pkg-c will
not even be allowed to be installed. If the force option is used,
then it should not disappear pkg-b because it is then still involved
in a contended pathname.
Thanks,
Guillem
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)