[Bug 1988819] Re: When apt keeps back packages due to phased updates, it should list them separately

[Xiao Wan]

To add a data point and save others from preventable headaches, I encountered a related bug and reported it here:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2017399

If anyone cares, here are my two cents regarding phased updates:
https://github.com/xwcal/ubuntu-apt-bug#a-short-critique-of-phased-updates

Or if lack of markdown formatting is not an issue, here is goes:

# A Short Critique of Phased Updates

Some thoughts after I stumbled on phased updates during a recent
migration from Bionic to Jammy:

## Randomness and Repeatability

Per [Debian repository
specs](https://wiki.debian.org/DebianRepository/Format#Phased-Update-
Percentage), randomization is achieved by the following means:

```
To determine whether an update is applicable to a given machine, a client shall seed a random number generator (APT uses std::minstd_rand) with the string:

 sourcePackage-version-machineID

where sourcePackage is the name of the source package, version the
version, and machineID the contents of /etc/machine-id.

It shall then extract an integer from a uniform integer distribution between 0 and 100. 
```

To the uninitiated: this is not how a random number generator is meant
to be used. If you want a repeatable sequence of random numbers, you
seed the RNG once and then draw the desired number of samples. You don't
reseed the RNG for each new sample, since if your seeds are already
random, then the RNG step is pointless, whereas if your seeds aren't
random, say, in an extreme case, if you always seed with the same
number, your "random" number is guaranteed to be the same each time.

To achieve repeatable randomness with respect to both the package and
machine, there is an obviously superior choice in terms of both
randomness and portability: **just use a cryptographic hash like
sha256**.

This begs the question of how repeatable the design really is.
To quote [https://wiki.debian.org/MachineId](https://wiki.debian.org/MachineId):

```
what is the machine id actually used for?

    a comprehensive list is probably not possible without grepping the code 
```

That's to say, although for repeatable experiments it's foreseeably necessary to mess with the machine ID or share it publicly,
the consequences of such tinkering or disclosure are hard to assess, since nobody knows for sure how and where the machine ID is and will be used.

This leads to an easily conceivable alternative: since apt only uses the
machine ID for the purpose of repeatable randomization, how about
designating another user configurable value stored in, say
`/etc/apt/phased-update-random-seed`, only for this particular purpose
and by default initialized to the machine ID?

## User Choice

>From [this
response](https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2017399/comments/1)
to my bug report (one question I forgot to ask is why phase security
updates at all) and a comment on
[askubuntu](https://askubuntu.com/questions/1431940/what-are-phased-
updates-and-why-does-ubuntu-use-them) that doesn't cite any source, it
does appear that consideration has been given regarding the need to
treat different packages (at least different classes of packages)
differently when it comes to phasing.

It's conceivable that a user may have preferences over how each
particular package is phased. For example, if a GUI component has a
troubled history with my Nvidia graphics, I may prefer to be highly
conservative and wait until the last minute, but this shouldn't prevent
me from being adventurous when it comes to other phased packages.

Unfortunately, it seems that a user currently has to decide between all
or nothing, ie. between `APT::Get::Always-Include-Phased-Updates` or
`APT::Get::Never-Include-Phased-Updates`.

How about allowing per package user choice between Always and Never?

Overall, I think for a such a prominent change to the cornerstone of
probably half of today's Linux infrastructure, much remains to be
desired.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1988819

Title:
  When apt keeps back packages due to phased updates, it should list
  them separately

Status in apt package in Ubuntu:
  Triaged

Bug description:
  After phased updates have been introduced, it may happen that apt
  upgrade shows packages as upgradable but ends up not upgrading them.
  In this case the packages are indicated as being "kept back".

  Unfortunately, the feedback provided about this to the user is not
  very informative. The user sees the packages being kept back and
  thinks something is going wrong on the system.

  When packages are kept back because of phased updates, apt should say
  so e.g., it should say that the upgrade is delayed.

  Incidentally note that aptitude does not respect phased updates.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: apt 2.4.7
  ProcVersionSignature: Ubuntu 5.15.0-47.51-generic 5.15.46
  Uname: Linux 5.15.0-47-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: KDE
  Date: Tue Sep  6 10:05:14 2022
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2020-02-16 (933 days ago)
  InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: apt
  UpgradeStatus: Upgraded to jammy on 2022-06-03 (94 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1988819/+subscriptions