Re: DEP 17: Improve support for directory aliasing in dpkg

[Ansgar <ansgar@43-1.org>]

Hi,

On Sun, 2023-05-07 at 07:50 +0200, Helmut Grohne wrote:
> But then, you only capture diversions inside Debian's ecosystem

It's unreasonable to support stuff outside Debian's ecosystem: even
basic dependency relations do not work for this.

Debian's dependency system requires to explicitly declare
Depends/Conflicts/Replaces/Breaks, but for obvious reasons we cannot do
that for packages outside Debian's ecosystem.

The same is true for diversions/alternatives/* or anything else
requiring coordination among all users: the dpkg ecosystem has too many
practical limitations to support non-Debian packages on anything but a
"it might work" basis (which is usually "good enough").  (This is even
true for packages within the Debian ecosystem, especially when one
considers partially implemented features like multi-arch.)

Is there any specific reason why specifically diversions are a problem
where "it might work" is not sufficient? That is, why should we divert
from the usual standard for dealing with packages outside the Debian
ecosystem here?

> I also caution that we've started from a very simple approach and tried
> fixing it up to address the problems that we recognized in analyzing it.
> My impression is that we are not finished with our discovery here and
> won't be for quite some time.

Well, we find limitations in dpkg that we in all other contexts usually
ignore. If we used similar expectations in other cases, we would need
to very much restrict when Breaks/Conflicts/Replaces might be used at
all: it's totally unrealistic to list all (possibly local) packages
that ship conflicting files, possibly only created by maintainer
scripts. Or to explicitly list all reverse dependencies that might be
broken by a particular change. We also would not have multi-arch yet as
the dependency system doesn't support it fully (some of which is
already known, but probably discovery isn't finished yet).

(Of course in some cases explicitly listing reverse dependencies can be
avoided: just always introduce something like

    Provides: ${foo}-compat (= 1)

for *all* dependencies and forbid `>=` in `Depends`; this allows to
stop providing that in cases where one would have to declare explicit
`Breaks` before. But only the direct provider can use this, so it's
already too limited... Alternatively forbid *all* changes that would
require this, i.e., require stable interfaces. However we do not do
this.)

But for all these issues we just say "meh, you are out of luck".

Ansgar