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

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



On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote:
> On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:
> > 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.)
> 
> I don't think this is the consensus view.

So why do we allow changes that require listing all reverse
dependencies in Breaks then? This is known to be wrong for all non-
listed packages, e.g., all local/vendor/derivative-specific packages.

> Our derivatives are among our users, for example, and we care about
> them being able to add packages in appropriate ways.

As far as I understand, we do explicitly *not* care about our
derivatives with regard to merged-/usr as some packages in Debian
recommend users to move *away* from merged-/usr to split-/usr on
derivatives, i.e., to an unsupported fs layout.

AFAIR the ctte felt that doing so on derivatives is fine for packages
in Debian (w/o an explicit formal ruling).

Ansgar


Reply to: