[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media

Fri Jun 22 12:53:56 CEST 2012

> 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.
+