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