Comment 3 for bug 83976

Edited log from #canonical today:

<cjwatson> cprov: as a matter of higher urgency, I'd rather that the constraint be fixed
<cjwatson> -security should not be required to be > -proposed or > -updates
<cjwatson> (-updates is slightly more questionable, but I think that makes sense; in any event this debate must not hold up fixing -security)
<cprov> cjwatson: nascentuploads is still a wild land, but the fix is feasible.
<cprov> cjwatson: pitti: we already keep BACKPORTS uploads version independent from RELEASE/UPDATES/SECURITY, I think we can do the same for PROPOSED
<pitti> cprov: well, all non-release pockets should be > release, this check makes sense
<cprov> in feel words, after this fix versions in SECURITY/UPDATES version won't be required to be higher than those in BACKPORTS/PROPOSED
<cjwatson> cprov: the only constraints that IMO make obvious sense are: uploads to !RELEASE must be > RELEASE; uploads to UPDATES must be > PROPOSED
<cjwatson> cprov: none of the other constraints make any kind of sense to me
<cprov> cjwatson: it's not that simple, I guess, working with post-release pockets(always higher than RELEASE): uploads to UPDATES/SECURITY > (ALL - BACKPORTS)[-1] AND uploads to BACKPORTS > ALL[-1]
<cprov> cjwatson: I will just exclude PROPOSED version checks for UPDATES/SECURITY
<cprov> I mean, exclude *also* PROPOSED ..
<cjwatson> cprov: I see no justification for bothering with the extra constraints you mention there
<cprov> cjwatson: it prevents uploads to updates < than what we have in security and vice-versa.
<cprov> cjwatson: but I agree it could be caught in pkg-review time
<cjwatson> cprov: I don't see why we should bother; it just causes panics like this
<cjwatson> and doesn't really buy us anything important
<cprov> cjwatson: it'd if was correct, no ?
<cjwatson> cprov: there are so many corner cases in how particular packages are handled that I strongly believe the versioning constraints enforced by the archive software on pockets should err on the
                  side of being relaxed
<cjwatson> cprov: for a start, your "vice-versa" above (preventing uploads to security < updates) is definitely wrong
<cjwatson> cprov: given that the current constraints are so wrong, I think they should be stripped back to the bare essentials and that every additional constraint should have clear thought and
                  justification
<cprov> cjwatson: yes, the reality proves your right.
<cjwatson> nothing scary is going to happen if those constraints are removed
<cprov> cjwatson: you made you point, could you comment it on 83976 ?
<cjwatson> but we're better off defending against that sort of thing by post-facto checking (i.e. send warning mails and stuff)
<cjwatson> cprov: sure
<cprov> cjwatson: thanks

To elaborate slightly on the -security vs. -updates check, the thing that the constraint is presumably intended to defend against is an upload to -security never making it out to users because there's already a newer version in -updates (which we assume does not contain the security fix). However, note that this can just as easily happen the other way round - an upload to -updates could be made with a higher version number than that in -security without containing the previous security fix, by an oversight. The sort of processes which defend against the latter can also defend against the former. The version check here gets in the way, because I can envisage situations where we might consider e.g. dapper and dapper-updates to be separately-maintained branches of a given package (there is already a case of this for -proposed, which is why all this came up) and might want to apply the security fix to both dapper and dapper-updates separately, but would be prevented from doing so by this constraint.