FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 12-12-2008, 04:43 PM
Les Mikesell
 
Default Making updates-testing more useful

Thorsten Leemhuis wrote:

>
But well, likely it doesn't matter to much anyway, as yum is still
pretty broken in such situations anyway, as mirror lags will confuse it:
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html



Yes, that's right yum is broken b/c the mirrors are out of sync.

>
Just like Apache is broken when a 404 is issued. It must be apache's
fault that the data is missing or broken.


I don't think the Apache example really flies, but whatever, not worth
arguing. I just want the problem fixed :-)


You have to know what is broken before you can fix it. One case is like
a farm of apache servers where you pull a page during a site update and
get a link to a target not updated yet. The fix there is to wait a
second. Another is that you have cross-site references where one site
changes a reference used by another. If that is planned, it may again
be a matter of waiting some indeterminate length of time for a natural
resolution. But, from the consuming end you really have no idea whether
the breakage is temporary and will resolve on its own schedule or if it
is accidental breakage that will continue until someone reports and
fixes it.


It depends a bit for what they use it -- sometimes it's Fedora that is
"broken", sometimes RPM Fusion/Livna, sometimes yum or sometimes
PackageKit. We all don't want that afaics; it's really bad for Fedoras
reputation.


So we should try to get it fixed; yum *afaics* is the best place, as the
data is there in the repos (at least if RPM Fusion pushes all the bits
at the same time; that works often, but now always), yum just has to
look at the right places *or* ignore those problems for some time *or*
<your suggestion here>.


Yum might ignore updates with very recent timestamps and failed
dependencies (if it knows anything about timestamps...). But I don't
think it knows much about which repo is supposed to be supplying a
dependency for the cross site stuff (a separate problem IMHO). How is
it it supposed to determine the cases that won't get fixed without
notification and intervention?


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 07:08 PM
Seth Vidal
 
Default Making updates-testing more useful

On Fri, 12 Dec 2008, Kevin Kofler wrote:


Seth Vidal wrote:

I bet it is not wrong. the i386 packages probably provide what was
required. They just provide it sub-optimally.


But that's really the problem: yum (*) thinks



as opposed to doing what? Everyone wants yum to magically solve problems
or if it cannot it needs to be able to distinguish b/t the 'next best'
solution and a 'bad solution'. Which is entirely variable.


What would you have it do?

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 07:12 PM
Seth Vidal
 
Default Making updates-testing more useful

On Fri, 12 Dec 2008, Kevin Kofler wrote:


Seth Vidal wrote:

I bet it is not wrong. the i386 packages probably provide what was
required. They just provide it sub-optimally.


But that's really the problem: yum (*) tries to resolve conflicting
requirements (of the A requires C = 1.2.3 and B requires C = 2.3.4 type) by
installing C.x86_64 = 2.3.4 and C.i386 = 1.2.3. This obviously can't work
(it will in almost all cases lead to file conflicts, and it is almost
certainly not what the user wants). I think there needs to be some
restriction that C.x86_64 and C.i386 need to be of the same EVR.


1. There's no way to know in advance that the above will be in conflict at
all. And for every case where it is most likely to be so I'm positive I
can (or have) find a situation where it is the opposite.


2. the better solution is %{_isa} being added to all deps/provides for any
pkg which COULD become a multilib pkg.




(*) (and other depsolvers too, I've seen apt-rpm do it too, but let's focus
on yum here)


all depsolvers have a problem when the dependency/provide information is
ambiguous.





(And sorry for the previous incomplete message, I accidentally hit
Ctrl+Enter and KNode sends the message immediately if I hit that.)


then I'm sorry about the cranky response to that message. I thought that
was all of the message and you were being flippant.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 12:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org