The main thing about this change is that any upload for *-security will go to the archive, even if the versions in e.g. stable and testing are the same. This sounds really easy. Even the detailed way (in case of an upload to proposed-updates: version larger than testing? If so, reject unless it's a security upload, and reject unless current stable version equals current testing version) doesn't sound too hard. But looking at details makes the mind spin: The information whether we upload to proposed-updates or to stable-security is lost really soon. Much worse is that the "current testing version" may have different meanings. Does it mean the version in testing, or in testing-proposed-updates, if there are both? And - how to write getting wise of this in a transparent, configurable way?
So, it took me some time, and multiple versions of the code to do it in a way where at least I can't see a flaw currently.
The first change is that there is a version-map, and during distribution-mapping, any matching version-mapping is recorded as "possible map" if there are version problems later on.
The second change is at the cross suite checks: If we detect a problem, than we check if there is a version-mapping for this upload. If not, we take the old exit. So, the new code is only entered for *-security-uploads. In the new code, there is a "generous" version detection code. If asking for a version in testing-propsed-updates, you'll get the newest version in any of testing and testing-proposed-updates. For this, there is a new "enhances" configuration item. proposed-updates enhances stable, and testing-proposed-updates enhances testing.
Now, there are all pieces together. If a package enters the new code (means: it's a security upload, and we failed some inter-suite dependencies), it is checked (in that order) whether the inter-suite dependencies fails even with the generous code (e.g. if it fails for testing, we check if it also fails for testing-proposed-updates). If it works there, we issue a warning and continue. If it fails, and the generous version is the same for the suite where the package is uploaded to and for the one it failed (e.g., if stable and testing have the same version), than the package is also targeted at the mapped extra suite (means: it may additionally go to testing-proposed-updates and even unstable for stable-security, and unstable for testing-security).
Wow. That was it. I hope that the remaining flaws are not too bad, so that this code could really be applied to katie, and we can continue with bringing amber in shape for testing-security support, which in turn is the major release blocker. For those of you who want to take a look, the patch is currently available at http://people.debian.org/~aba/dak.patch.
I planned to also play with tiffani, a proposed member to the harem. Her task would be to care about diffs, to shorten download-time for apt-get update. A test version already exists (most code by Anthony, only some glue code by me), but some small issues still need to be looked into. However, katie and jennifer took enough of my time, so I postponed it till later this week.