[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Corner case: can a package owning a diversion disappear?



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


Reply to: