Re: DEP 17: Improve support for directory aliasing in dpkg
On Sun, 7 May 2023 at 10:14, Ansgar <ansgar@43-1.org> wrote:
>
> 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".
Indeed, if we don't worry about local random changes or random third
party packages beyond documenting what needs attention, we shouldn't
worry about them for this either. As already mentioned lots of third
party packages don't even use Debian's toolchain to build packages, so
there's nothing that we can do anyway.
Kind regards, Luca Boccassi
Reply to: