upgradepath and updates-testing - summary of problems

Kamil Paral kparal at redhat.com
Wed Sep 29 13:41:29 UTC 2010

This is a summary of all problems related to upgradepath test and the
updates-testing repo.

First of all, upgrade path requirement is not properly defined anywhere.
The best what I could find is this:

That means we work mainly on assumptions.

For base and -updates repo, this is not a big problem, the task is pretty

Algorithm example
Repo set RS = base + updates
For every Fedora release F:
  For every package P in RS of F:
    NVR of P <= NVR of P in RS of F+1

We must check this constraint for every pending package update, right before
it is pushed.

We have this already implemented, and when it is enforced, we will guard 
all the common users (common user == using just base + updates repo set) 
against upgrade path problems.

For -updates-testing repo however, things are not as easy.

Problem #1: What is the desired repo set?

In the algorithm example, repo set of F and repo set of F+1 were equal (base +
updates repos). How does repo set look like when -updates-testing is in place?

Do we want to check it this way?
a) F base + updates + updates-testing => F+1 base + updates + updates-testing
or this way?
b) F base + updates + updates-testing => F+1 base + updates

Option a) is simple, we use the same approach as in the algorithm example. But
it may not really guard the user, see following problems.

Option b) guards the user well, but it has some serious drawbacks. It basically
says that you must first push into F+1-updates before you can push to 
F-updates-testing. That can have a large impact on package maintainers workflow.
If you consider that it may take one or two weeks before your update is pushed
into -updates, then it may a whole month or more before your update propagates
from Rawhide to Rawhide-3.

1. In all repos there is foo-2.0.
2. I want to push foo-3.0 into Rawhide, F14, F13 and F12.
3. First I must push to Rawhide.
4. Once it is in Rawhide, I can push to F14-updates-testing.
5. Now I must wait until testers give me enough karma, and then push it into
6. Only now (not before) I can push F13-updates-testing.
7. Now I must wait until testers give me enough karma, and then push it into
8. Only now (not before) I can push F12-updates-testing.

Only FESCo may say whether this is the desired workflow for package 
maintainers. It is certainly different from current practice.

Problem #2: Removing repositories

Option a) in Problem #1 sounded nice, didn't it? Well, not so much.

A problem arises when you disable -updates-testing repo. Either by hand
(a power-user downloaded a few packages from this repo because he wanted
to test new versions of his favorite software or test some bugfix, and then
he disabled this repo again) or automatically (anaconda disabled 
-updates-testing on distribution upgrade - I don't know whether this is
actually done, but anaconda developers don't know either:)).

After you disable this repo, you still might have some packages installed
that are newer than those in F+1 base+updates. That is a problem, we haven't
saved this user from upgrade path problems in this case.

Problem #3: Unpushing packages

Even more juicy problem exists - unpushing packages from -updates-testing.
If we use Option a) in Problem #1, we still can't have any confidence in
our results. Because our results will apply only in that precise moment when
we check it. An hour later the corresponding package may be unpushed from
F+1 updates-testing, but left intact in F updates-testing (or you already
downloaded it, that's the same). And voilà, we have an upgrade path problem.

1. foo-3.0 is pushed into F12-updates-testing and F13-updates-testing.
2. User installs foo-3.0 from F12-updates-testing.
3. foo-3.0 is unpushed from F13-updates-testing.
4. Upgrade path problem.

1. We don't know exactly how upgradepath constraint is defined.
2. We have no idea what -updates-testing should be tackled.
3. We should ask FESCo what's the preferred approach.
4. Current proposed solution is: "Updates-testing is for power-users, they 
   will handle possible problems. After we receive some info how to proceed
   in this matter, we can extend our code."
5. Basic base+updates repo checking seems simple and is already implemented.
   All common users should be safe.

If you see some logical mistakes or gaps in this email, please correct it.
There might be some further issues that didn't occur to me.


More information about the autoqa-devel mailing list