[continued from previous message]

should have been the way to do it), has been done, which:
- Switches the source of truth from the .deb to the fsys.

While this is correct on some level, the aim of this change is to put
that truth back into dpkg of course.

Sure, the problem is the price that will need to be paid to get there,
in terms of problematic interfaces or behavior and what kind of
workarounds or hacks that will entail, and for how long.

- Confuses admin initiated changes from distro initiated ones.

I think we already do this with dpkg-divert, dpkg-statoverride and other tools. While this may not be nice, it certain has prior art and is
consistent with how we have been doing things in the past.

dpkg-divert distinguishes between local and package level changes, it
is true that dpkg-statoverride does not have (currently) that
distinction, although it is primarily an admin tool where I don't
think it makes much sense to support something like declarative
package statoverrides TBH once we can ship fsys metadata (perhaps
conditional one though).

* Wants to be a generic change but it is really targeted to this
specific mess. We have been doing similar aliasing transitions for
many doc dirs, by stopping shipping files within, shipping that
pathname as a symlink and then switching the directories to symlinks
to match (via the dpkg-maintscript-helper hack because we miss fsys
metadata). This means we'd need to then register all these directories
too? Meh.

I would love to agree with this, but I believe that this ship has
sailed. This likely is part of our fundamental disagreement.

The comment was not focused on how this could have been done, but in
that this is a common operation we do, and would need to get the same treatment, which seems bad.

* This information can get out of sync with reality, as it adds an
additional and unconnected with anything source of truth, that dpkg
cannot do anything about if it diverges (in contrast to diversions
or statoverrides f.ex.). This can never happen when that information
comes from the real source of truth (the fsys metadata via the .deb).

I have difficulties accurately capturing the argument. The problem of information getting out of sync with reality should affect every aspect
of dpkg and indeed, that kinda is the status quo where upgrades can
loose files, because dpkg has an incomplete picture of reality. The aim
of this change is to allow us to re-sync the status quo into dpkg. My
view is that dpkg's information presently is out of sync with reality
and the proposed change partially fixes that.

The current problem stems from both dpkg lacking fsys metadata and
Debian holding dpkg wrong in an unsupported way, but where ideally
both of these will eventually go away (?). My objection was that the
proposal introduces a mechanism which makes things worse because it
adds more information sources that can/will get out of sync.

[ As an aside, I think ideally eventually nothing distro provided should
be allowed to be installed within an aliased dir, and dpkg should
eventually just error out in those cases, which eventually would get
rid of the aliasing problems and any such complexity (I'm not sure how
or when that would be feasible though, but obviously in Debian at
least not until nothing ships files there). ]

It seems to me that this is something everyone agrees on. So our
disagreement resides in the way to get there rather than where to get
to.

If that's the case, then great. My impression though is that some
people expect dpkg will be able to unpack content within aliased
directories (?), which I don't see happening for the reasons I
mentioned above. This will imply that you cannot install any old
package that ships content there, which might be unexpected, but I
don't see any other sane way to handle this. :/

So this still looks like a terrible interface, like it did at the time
it was discarded; founded on a hack, an interface that seems wants to
be kind of a file-type override but it cannot be, and cannot even
properly act as record tracker, etc…

I agree that in a perfect world, we would not need this. Let me circle
back to our fundamental disagreement.

My impression is that at this time basically everyone except you agrees
that we have to deal with the aliasing problems that have been rolled
out to users and will be forced in bookworm. I believe that this is the
state that we have to consider as starting point and that we cannot
magically turn this transition back to perform it in a better way. And indeed, I believe that there would have been a better way[1] that no
longer is available to us.

I think I've mentioned before multiple times, that dpkg should
eventually be able to be aliasing-aware. I think I've also mentioned
that to get there we need to move all files out of aliased directories, otherwise several of the changes required for that "support" might not
be even able to be deployed.

On the other hand, my impression is that you continue to see the
transition as fundamentally broken and in a state that we cannot work
from. You appear to believe that if we want to do it, we must start over
in a better way. That better way must not cause aliasing problems to
dpkg.

Well, it should be obvious by now this somewhat called transition is fundamentally broken, and I also see that there is no magic simple and
clean way to get out of it. And every way out, is through further
complexity, workarounds or badness. Of course given the corner Debian
has painted itself into, there needs to be a way out, my objection is
what kind of price to pay for that.

I thought it would be clear that if there is stuff that depends on
any of this kind of changes to dpkg, relying on those changes in
Debian would not be possible until after trixie+1. Of course there is always the route to further pile up over the Jenga tower of hacks,
by for example adding huge amounts of Pre-Depends…

I agree that we probably will deal with this until at least trixie+1.
This is precisely why I would like to have a plan to finish it sooner
rather than later.

Also, to note, that even if the way out was through some dpkg
workaround, which would even get backported to bookworm, AIUI upgrades
are never guaranteed to start from the last point release, so that
would not seem to help much anyway.


So coming back to workarounds and hacks, I'm finding the diversions
stuff to be rather bad, as it requires to bypass an explicit dpkg
refusal to deal with diverted directories, so it's going into further unsupported territory. :/ My other concern is that this might end up
leaving unsupported directory diversions around which could break dpkg
if it starts refusing to work on them during unpack, not just during
diversion additions.

I did a PoC (untested) implementation for the partial upgrade deletion prevention workaround to see how bad that might look like, and in
comparison to the diverted stuff it is bad but not as bad. As I
mentioned on our talks, this needs to imply emitting a warning,
because otherwise this might end up as relied on behavior that should
not be supported, and it would be a temporary hack for Debian and
derivatives until things have moved out.


[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)