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

AL13N alien at rmail.be
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.


More information about the Mageia-dev mailing list