Making updates-testing more useful

[Paul Howarth]

Seth Vidal wrote:
> 
> 
> On Fri, 12 Dec 2008, Christopher Stone wrote:
> 
>> On Fri, Dec 12, 2008 at 8:43 AM, Jeff Spaleta <jspaleta at gmail.com> wrote:
>>> On Fri, Dec 12, 2008 at 6:55 AM, Seth Vidal 
>>> <skvidal at fedoraproject.org> wrote:
>>>> In general skip-broken is probably going to need to be the default 
>>>> for these
>>> Yes, having skip-broken notify users of the problems its going to skip
>>> over, and not silently skip would make me feel better. There will be a
>>
>> --skip-broken is borked, I used it the other day with the PackageKit
>> problems, and skip-broken tried to pull in a bunch of .i386 deps (I
>> don't have any .i386 rpms installed on my system).  It did manage to
>> skip the broken rpms, but it also tried to pull in a bunch of .i386
>> rpms as well which is obviously wrong.
>>
> 
> I bet it is not wrong. the i386 packages probably provide what was 
> required. They just provide it sub-optimally.

I get this quite a bit (and I don't use skip-broken), as I keep a local 
mirror of updates for packages that are on the DVD (my quick heuristic 
for the most common ones) and let the rest get pulled from the Internet. 
I update my local mirror when I see the package announcements on 
fedora-package-announce, so it's usually updated before many of the 
other mirrors.

The problem happens when I have two packages installed that have a 
versioned dependency relationship and where one can be found on my local 
mirror and the other needs to be pulled from the Internet, and the 
package that is "required" is multilib.

Suppose B is a subpackage of A,
with B requiring A = %{version}-%{release}, A being on the release media 
and B not being. So when A is updated, I see the update of A first.
When I do a "yum update", and updated version of A is available but no 
update to B is visible. My installed version of B needs the installed 
version of A, but A is about to be upgraded. This would normally cause a 
dependency issue and fail, but if A is multilib, the dependency can be 
satisfied by installing the original version of A.i386 in parallel with 
the new version of A.x86_64. This then pulls in all of the i386 deps of 
A. I tend to work around this by adding B to the list of packages I 
mirror locally when I see this sort of problem.

Whilst my arrangement is unusual and makes me more prone to seeing this 
sort of problem, there are other scenarios in which it could happen, 
e.g. where there are versioned cross-repo dependencies.

Paul.