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

[Simon Richter <sjr@debian.org>]

Hi,

On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:

> At some point the question becomes: Do we want that complexity inside
> dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what
> we're talking about here). It seems clear at this time, that complexity
> is unavoidable.

My gut feeling is that returning to "dpkg's model is an accurate
representation of the file system" will be less complex to manage
long-term. For this to work, the model needs to be able to express
reality, so I guess we can't avoid updating dpkg.

I'm also not convinced that the current filesystem layout will remain as
it is, for example I can see a use case for installing kernel modules
outside of /usr. It would be great to have a generic mechanism here, and
be able to do transitions like these without inventing new tools every
time.

Also, the more we can do in a descriptive framework, the better we can
do static checks. The main reason we can argue about what packages are
affected is that we have a database of what files are installed where,
and that still accurately reflects reality, so we can apply a
transformation onto this data and check for conflicts -- but we cannot
see diversions in this database as these are created from imperative
code.

So my fear is that if we create a workaround here that is implemented as
imperative code in pre/postinst, this will be invisible to whoever plans
the next transition, so this would create immense technical debt.

   Simon