Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Simon,
On Thu, May 04, 2023 at 03:37:49AM +0900, Simon Richter wrote:
> For aliasing support in dpkg, that means we need a safe policy of dealing
> with diversions that conflict through aliasing that isn't "reject with
> error", because the magic dpkg-divert would always generate conflicts.
I think we still have that misunderstanding I mentioned earlier, so let
me try to resolve that again.
>From my point of view, the ultimate goal here should be moving all files
to their canonical location and thereby make aliasing effects
irrelevant. Do you confirm?
As such, I do not see aliasing support in dpkg as complementing the
forced file move approach with lots of workarounds such as diverting
dpkg-divert. Rather, I see them as exclusive strategies. Each of these
strategies has significant downsides. In combining the different
strategies, we combine their downsides, but since their benefit is
shared, we do not gain anything in return but increase the price to pay.
Why should we do that?
So when we discuss diverting dpkg-divert, I imply that we do not change
the implementation of dpkg wrt. aliasing. So this branch of discussion
that you raise here, seems irrelevant to me.
On the flip side, if dpkg (and thus dpkg-divert) is to gain aliasing
support, I see no reason (and benefit) to diverting dpkg-divert.
Can you explain why you see combining these strategies as something
worth exploring?
> then a package containing /bin/foo and a package containing /usr/bin/foo now
> have a file conflict in dpkg. Not sure if that is a problem, or exactly the
This case already is prohibited by policy section 10.1. It can only
happen as a temporary state during a file move (from / to /usr and from
one package to another).
> behaviour we want. Probably the latter, which would allow us to define a
> policy "if aliased paths are diverted, the diversion needs to match", which
> in turn would allow the conflict checker during alias registration to verify
> that the aliased diversions are not in conflict.
If we do not modify dpkg to improve aliasing support, then yes, such a
scenario will require a Conflicts declaration or a different measure
averting this problem.
> The diverted dpkg-divert would probably generate extra register/unregister
> calls as soon as dpkg-divert itself is aliasing aware, but all that does is
> generate warning messages about existing diversions being added again, or
> nonexistent diversions being deleted -- these are harmless anyway, because
> maintainer scripts are supposed to be idempotent, and dpkg-divert supports
> that by not requiring scripts to check before they register/unregister.
Again, the premise seems unreasonable to me. Also note that such a
diversion of dpkg-divert certainly is meant as a temporary measure
facilitating the transition. I'd hope we could delete it in forky
already and failing that thereafter.
> We get to draw this card exactly once, and any package that would need the
> same diversion would need to conflict with usr-is-merged, which would make
> it basically uninstallable.
I don't think the case of packages wanting to divert update-alternatives
is all that common. Please elaborate on the use case. Also note that
this suggestion already is to be considered a plan B. My current
understanding is that as long as we do not canonicalize alternatives at
all, we don't run into problems with them. This kinda is ugly, but the
number of affected packages is small.
Helmut
Reply to: