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

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



Hi Raphaël,

On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote:
> I don't know APT well enough to answer that question but from my point of
> view it's perfectly acceptable to document in the release notes that you
> need to upgrade dpkg first.

Yes, this issue seems vaguely solvable one way or another. It also
affects other approaches modifying dpkg in the very same way.

> Are you sure that we need anything for diversions except some documented
> policy on how to deal with it?

Yes! There is a hard ordering constraint involved here. Failure to do so
results in unpack errors and or file loss in much the same way.

> AFAIK the following sequence performs no filesystem changes and should
> be sufficient to move a diversion to its new location (I only consider the
> case of an upgrade, not of a new installation that should just work
> "normally" on the new location):
> 
> dpkg-divert --package $package --remove /bin/foo --no-rename
> dpkg-divert --package $package --add /usr/bin/foo --divert /usr/bin/foo.diverted --no-rename

This is insufficient. Either we modify dpkg to consider aliasing when
managing diversions (i.e. Simon Richter's branch or DEP17) or there is a
more complex ordering requirement involved:

 * We must not remove the aliased diversion (/bin/foo) before the
   diverted package has moved its files to the canonical location
   (/bin/foo -> /usr/bin/foo).
 * We must add the canonical diversion (/usr/bin/foo) before the
   diverted package update that moves its files to canonical locations
   can be unpacked.

Say we currently have

Package: diverter
Version: 1
Files: /bin/foo
preinst: diverts /bin/foo

Package: diverted
Version: 1
Files: /bin/foo

We must first update the diverter.

Package: diverter
Version: 2
Files: /usr/bin/foo
preinst: diverts both /bin/foo and /usr/bin/foo

Since we divert both locations, diverter can now deal with an old
diverted and a canonicalized diverted.

Package: diverted
Version: 2
Conflicts: diverter (<< 2~)
Files: /usr/bin/foo

At the time of unpacking the updated diverted, we must ensure that no
diverter versioned 1 is unpacked. Breaks does not help here as it allows
concurrent unpacks. Neither does Replaces since dpkg thinks that
/bin/foo is different from /usr/bin/foo and thus no replacing happens.

Package: diverter
Version: 3
Conflicts: diverted (<< 2~)
Files: /usr/bin/foo
preinst: diverts /usr/bin/foo

When unpacking the updated diverter, we must ensure that no diverted
version 1 is unpacked. Again, Breaks and Replaces does not suffice.
Therefore an upgrade from stable to nextstable containing both diverter
and diverted must temporarily remove either package, which is known to
annoy apt.

What still applies here is that we can have usr-is-merged divert
/usr/bin/dpkg-divert and have it automatically duplicate any possibly
aliased diversion and then the diverter may Pre-Depends: usr-is-merged
(>=...) to have its diversions duplicated. Of course, doing so will make
usr-is-merged very hard to remove, but we have experience here from
multiarch-support.

Hope this clarifies.

> The case of update-alternatives is likely more tricky. You already looked
> into it. That's a place where it will be harder to get things right
> without some changes.

As detailed in
https://lists.debian.org/debian-devel/2023/04/msg00169.html I believe
that update-alternatives really are not tricky at all as long as we do
not attempt to migrate them to canonical paths in any way. For instance,
elvis-tiny needs to continue to name the editor alternative
/bin/elvis-tiny even when it actually moves that file to /usr/bin. The
reason that this does not hurt is that we never attempted to move
alternatives (unlike regular files in packages).

If we really want to migrate alternatives to canonical paths, we do get
into the tricky area of preserving the user configuration and we also
break custom scripts, ansible's community.general.alternatives, uses of
puppet's alternatives modules and probably a lot more.

And of course, we can always draw the diversion card and have
usr-is-merged divert /usr/bin/update-alternatives to have it
canonicalize paths as required to be able to migrate alternatives in a
sane way (from a consumer point of view).

Helmut


Reply to: