Monthly Updates versus Monthly Images

[Dmitrijs Ledkovs]

On 7 March 2013 09:37, Robie Basak <robie.basak at canonical.com> wrote:
> On Wed, Mar 06, 2013 at 09:58:41PM +0000, Dmitrijs Ledkovs wrote:
>> Everything gets uploaded into -proposed, FTBFS / installability /
>> components mismatches are sorted out [*] / autopkgtests [*] are run
>> and then the packages are finally migrated by britney into rolling as
>> it is currently done.
>>
>> At this point all of these packages are phased at 0%. [1]
>> Over the period of time (e.g. 4 weeks) we gradually phase those
>> packages to 100%.
>
> From the spec:
>     A computer is in the testing set if
>               Phased-Update-Percentage ✕ 2^128
>                                ≥
>               md5(machine id + package name + package version).
>
> With precise-updates (for example), ordering of phasing between packages
> doesn't matter, since the dependency tree generally remains the same.
>

It does and it doesn't. So for example foo:src can build foo:amd64 and
foo-data:all with a strong version matching dependency.
I think it's nice to consider this as a general case, stress test
phasing in the development release before starting to use it for the
SRUs.
In general SRUs, will have less packages in phasing simultaneously
with much "lighter" dependency resolution.

> With rolling updates, won't phasing ordering start to matter? What
> happens if the results of my md5 cause an update to package A to be
> phased in before NEW package B, and the updated A now depends on B?

Yes, we should ideally, consider all dependency variants, with all
combinations of which packages "md5/phasing" hits/chooses to install
_now_ and record them in the test-suite.

> Presumably dist-upgrade can hold that specific case automatically, but:
>

apt-get / aptitude have no idea about phasing at the moment. So any
dist-upgrade from command-line / synaptic will be as if you agree to
install all packages even if at 0% phasing.
Only update-manager knows about phasing.

We do not want to hold any special cases. Instead we will agree that
if we choose to install a phased update, it's dependencies must be
satisfied and upgraded as necessary required. That means that the
update will succeed, but it will also mean that we are overphasing[1]
some packages.
In the simple case of foo & foo-data, if one "hits" either of updates
both are installed.
In the more complex case (a lot of reverse dependencies) e.g. like a
core library libgtk, the overphasing will be much significant, thus
core packages should be (a) tested more before uploads (b) phase much
slower, as reverse-dependencies will overphase them.

>   1) Are there more complex cases that will break things?
>

In theory, since apt-get is in the end installing packages and should
resolve all dependencies correctly, it should all just work ;-)
But we do not now yet what happens in the corner cases. We have
test-suites in the update-manager and cjwatson, ev and I discussed to
improve it with more "lets see, what if this happens".

>   2) Is holding going to cause any other problems? User confusion? More
>      invalid bugs as people wonder why they can't install things or "fully
>      update"?

This point is moot, since `apt-get dist-upgrade` should always work
(due to britney installability transitions) and we ignore phased
updates constraints when resolving dependency chains of the
phased-update.
Ideally I'd like to see phased-updates to be installed silently /
automatically. Just like apps are updated on the phones.

[1] defining "overphasing" is tricky, as we have no control over how
often users connect to the internet and/or set their dials to
automatically refresh package lists and actually apply phased updates.
It's purely theoretical relative comparison between packages.

Regards,

Dmitrijs.