Making updates-testing more useful

[Thorsten Leemhuis]

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