> AL13N skrev 21.6.2012 21:09: >> Op donderdag 21 juni 2012 19:01:51 schreef Claire Robinson: >>>> since QA is waiting for a fix for this for a long time (pre-mga1), we >>>> should get this fixed asap. >>>> >>>> PS: since we're enabling backports, we should make sure that the >>>> update >>>> validation process would have one of both required tests for >>>> validation >>>> with backports enabled and the other disabled. >> [...] >>> It is doubled now because we have two releases and most updates include >>> both. It will be effectively quadrupled with this plan and that would >>> be >>> unsustainable. We just don't have the manpower or enough hours in a >>> day, >>> we are struggling to cope as it is. >> [...] >> >> actually, it doesn't need to be. >> >> you already test twice before validating updates, right? >> >> so, there's 2 options: >> >> - testing i586 with backports enabled >> - testing x86_64 without backports enabled >> >> this is still 2 tests, and this is sufficient. >> > > NO. > > First of all, _anything_ heading for updates that is not noarch needs > to be validated on both arches. > > Secondly, when QA validate stuff for /updates, they dont need > to test _anything_ against backports as /updates is _only_ used to > fix stuff in /release & /updates. > > If something in backports breaks as a result of something going to > /updates, that's a separate bug against backported package and will > be handled after. > > Remember that /updates is priority 1, and /backports is handled > as QA time permits at lower priority.
I do agree with you here, except that i'm trying to prevent this from happening, because it's not something that can be easily fixed. 1. package A is backported into X 1b. package A-foo is backported into X-foo (subpackage) 2. package B is updated into Y at a later date 3. package update Y has a new dependency A-foo 4. person has X installed; but didn't install X-foo. 5. person updates B into Y result is that Y pulls in as new dependency A-foo but X conflicts with A-foo so the update does not happen, and you get an ugly error. my point is that: 1. since it's a new dependency, we can't know before we backport A that it would be used as a new dependency for an update. because the update isn't there yet, so we don't know beforehand. 2. more importantly, i don't see anyway to get this fixed without the user manually fiddling with things (downgrading back to unbackported package; or manually installing X-foo;) Maybe i'm looking too far ahead, but unless i'm missing an obvious way to cleanly fix this at the time of the update, this is still something we should avoid.
