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, 02:55 PM
Seth Vidal
 
Default Making updates-testing more useful

On Fri, 12 Dec 2008, Thomas Moschny wrote:


2008/12/12 Seth Vidal <skvidal@fedoraproject.org>:

A dependency problem in the set of packages provided by
(fedora base, updates from today, rpmfusion from today)
is somehow more 'severe' than a dependency problem from
(fedora base, updates from today, rpmfusion from yesterday)


How? It's the same to the user. They can't do what they wanted to do b/c
they're out of sync.


That's not true. They could go and report the dependency problems
somewhere - which would be superfluous work in case their mirror is
simply behind. And btw, how do you know what they really wanted -
probably they simply run yum upgrade.



Which is really what --skip-broken is for.

In general skip-broken is probably going to need to be the default for
these multi-repo situations. I don't LOVE it but if we tie this info into
the updateinfo.xml so we can properly notify the user if a security or
important update cannot be applied b/c of a broken dependency, then I will
feel better about it.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 03:14 PM
Thorsten Leemhuis
 
Default Making updates-testing more useful

On 12.12.2008 16:00, Seth Vidal wrote:


On Fri, 12 Dec 2008, Thorsten Leemhuis wrote:
Another good question (related to the "will this confuse new users" part):
Will you enable the updates-testing repos from 3rd party repos in the same
step automatically? Otherwise people that use those repos will now and then
run into dependency troubles -- for example when a new xine-lib enters
updates-testing from Fedora and xine-lib-extras-nonfree enters
updates-testing from RPM Fusion at the same time.


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 :-)


Cmon, Thorsten, your command of english is excellent, you can phrase that
a bit better.


Hehe, actually I had written the word "broken", then deleted it, and
then (after a few seconds) wrote it again. Mainly for one reason():
users often use it when they run into troubles outlined in

https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html

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


What would you suggest to fix the problem at hand?

Cu
knurd

() maybe I also a tiny little bit hoped it would help to get your
attention (sorry for that) so we can finally work out a solution (with
or without yum) to solve the problem once and for all


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 03:30 PM
Thorsten Leemhuis
 
Default Making updates-testing more useful

On 12.12.2008 10:55, Richard Hughes wrote:

On Fri, 2008-12-12 at 07:06 +0100, Thorsten Leemhuis wrote:

On 11.12.2008 19:28, Richard Hughes wrote:

Yes, we can easily enable the testing repos with a small button and a
more info link. The real question is, will this clutter the UI and
confuse new users?
Another good question (related to the "will this confuse new users"
part): Will you enable the updates-testing repos from 3rd party repos in
the same step automatically?


Yes.


Great!


If the user has fedora and rpmfusion enabled, but livna disabled,


Just to me sure: I assume you meant both rpmfusion repos (free and
nonfree) when you wrote "rpmfusion"?



it'll do in the first pass:

updates from all configured and enabled sources

and on the second pass:

disable fedora and rpmfusion


Disable? Why disable any repos? What is a package from one of the
testing repos introduces a new dep that is only solved by a package in
fedora (stock repos) or fedora-updates?



enable fedora-testing and rpmfusion-testing
updates from all configured and enabled sources
enable fedora and rpmfusion
disable fedora-testing and rpmfusion-testing

If you've got livna installed then it shouldn't touch the repo.


The new livna repo (that users get that install the current release
package from the rlo front page) afaics has no testing area anymore, so
it afaics should not matter at all and not get touched (like you said)



The
tricky bit is the heuristic that matches up rpmfusion-testing to
rpmfusion.


Maybe all that is needed it to enable all "*-testing" repos. Then it
would work even for other repos as well. But maybe that's to dangerous.


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

We can't do much about mirror lags, but we do switch on --skip-broken by
default which sort of mitigates things.


I'm not really sure of "skip-broken" in its current form really is the
best way to solve it, but maybe it's "good enough". Another subthread in
this discussion hopefully gets to a result.


Cu
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 03:39 PM
Richard Hughes
 
Default Making updates-testing more useful

On Fri, 2008-12-12 at 17:30 +0100, Thorsten Leemhuis wrote:
> On 12.12.2008 10:55, Richard Hughes wrote:
> > On Fri, 2008-12-12 at 07:06 +0100, Thorsten Leemhuis wrote:
> >> On 11.12.2008 19:28, Richard Hughes wrote:
> >>> Yes, we can easily enable the testing repos with a small button and a
> >>> more info link. The real question is, will this clutter the UI and
> >>> confuse new users?
> >> Another good question (related to the "will this confuse new users"
> >> part): Will you enable the updates-testing repos from 3rd party repos in
> >> the same step automatically?
> >
> > Yes.
>
> Great!
>
> > If the user has fedora and rpmfusion enabled, but livna disabled,
>
> Just to me sure: I assume you meant both rpmfusion repos (free and
> nonfree) when you wrote "rpmfusion"?

Whichever you have enabled. It's just a repo ID to PK.

> > it'll do in the first pass:
> >
> > updates from all configured and enabled sources
> >
> > and on the second pass:
> >
> > disable fedora and rpmfusion
>
> Disable? Why disable any repos? What is a package from one of the
> testing repos introduces a new dep that is only solved by a package in
> fedora (stock repos) or fedora-updates?

Else you report some updates twice.

> > enable fedora-testing and rpmfusion-testing
> > updates from all configured and enabled sources
> > enable fedora and rpmfusion
> > disable fedora-testing and rpmfusion-testing
> >
> > If you've got livna installed then it shouldn't touch the repo.
>
> The new livna repo (that users get that install the current release
> package from the rlo front page) afaics has no testing area anymore, so
> it afaics should not matter at all and not get touched (like you said)

Right.

> > The
> > tricky bit is the heuristic that matches up rpmfusion-testing to
> > rpmfusion.
>
> Maybe all that is needed it to enable all "*-testing" repos. Then it
> would work even for other repos as well. But maybe that's to dangerous.

I think some people might get upset by that.

> >> 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
> > We can't do much about mirror lags, but we do switch on --skip-broken by
> > default which sort of mitigates things.
>
> I'm not really sure of "skip-broken" in its current form really is the
> best way to solve it, but maybe it's "good enough". Another subthread in
> this discussion hopefully gets to a result.

Right.

Richard.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 03:43 PM
"Jeff Spaleta"
 
Default Making updates-testing more useful

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
> multi-repo situations. I don't LOVE it but if we tie this info into the
> updateinfo.xml so we can properly notify the user if a security or important
> update cannot be applied b/c of a broken dependency, then I will feel better
> about it.

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
vocal minority who will still report some of that breakage.

And since I'm asking for ponies, if there was an mechanism to drive
broken dep information back to the affected repositories via an email
or bugzilla drop that would also help me feel better.

The absolute worst thing we can do is to just silently ignore by default.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 03:48 PM
"Christopher Stone"
 
Default Making updates-testing more useful

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.

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

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.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 04:20 PM
Paul Howarth
 
Default 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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 04:30 PM
Kevin Kofler
 
Default Making updates-testing more useful

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 04:35 PM
Kevin Kofler
 
Default Making updates-testing more useful

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.

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

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

Kevin Kofler

--
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 07:57 AM.

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