[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Making updates-testing more useful



Seth Vidal wrote:


On Fri, 12 Dec 2008, Christopher Stone wrote:

On Fri, Dec 12, 2008 at 8:43 AM, Jeff Spaleta <jspaleta gmail com> wrote:
On Fri, Dec 12, 2008 at 6:55 AM, Seth Vidal <skvidal 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]