Re: /usr-move: Do we support upgrades without apt?

[Helmut Grohne <helmut@subdivi.de>]

On Wed, Jan 03, 2024 at 08:07:53PM +0100, Wouter Verhelst wrote:
> Presumably the reason for this requirement in policy is that without it,
> debootstrap cannot function. That is, debootstrap first unpacks all
> Essential packages, without running any preinst or postinst scripts, and
> *then* runs all the maintainer scripts. If an Essential package would
> not function without its maintainer scripts being run, then debootstrap
> could fail halfway through.

The requirement you reference above probably is 3.8:

    Essential is defined as the minimal set of functionality that must
    be available and usable on the system at all times, even when
    packages are in the “Unpacked” state.

I note that this does not apply to bootstrap as is later clarified:

    Since dpkg will not prevent upgrading of other packages while an
    essential package is in an unconfigured state, all essential
    packages must supply all of their core functionality even when
    unconfigured after being configured at least once.

The "at least once" was added precisely, because packages are not
required to work before having been configured at least once. What
happens during debootstrap is rather unspecified by policy. The
requirement really aims at upgrade scenarios where the other packages
are being configured when an essential package is unpacked but not yet
configured. This is precisely the situation we break here (if using dpkg
directly in unfortunate ways).

> Running debootstrap cannot trigger the issue, because it does not
> involve upgrades; and I do not believe that apt will special-case
> Essential packages other than that it refuses to remove them unless
> the user enters The Phrase[1], so we can consider that if it's something
> that would work for a regular package, it will work for an Essential
> one, too.

I agree: The file loss cannot be encountered with bootstrapping tools
and as long as we are interacting via apt (or some apt using tool), we
cannot create the broken situation (there actually is no proof of this,
just hope and having tried to break it) as long as there is no mutual
conflict.

> Perhaps if the above assumptions are correct, policy should be updated
> such that the requirement is relaxed to only apply for initial
> installation?

Policy has been updated via #1020267 to *not* apply to the bootstrapping
scenario.

Helmut