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: https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Miscellan...
That means we work mainly on assumptions.
For base and -updates repo, this is not a big problem, the task is pretty straightforward:
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.
Example: 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 F14-updates. 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 F13-updates. 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.
Example: 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.
Conclusion ---------- 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.
Thanks, Kamil