kde4.4 in updates-testing

[Thomas Janssen]

2010/2/17 Patrick O'Callaghan <pocallaghan at gmail.com>:
> On Wed, 2010-02-17 at 15:49 +0100, Thomas Janssen wrote:
>> > 2) not restricting yourself to kde* (and its dependencies) increases
>> the
>> > risk of a flaky system because you're updating a bunch of stuff you
>> > don't care about. It can then be hard to back out to *not* using
>> > updates-testing for every future update.
>>
>> Well. Not true. Whatever is in updates-testing, you should care of.
>> Most updates are bugfixes and come in 99.99% of the cases into updates
>> anyways.
>
> I mean that unless I'm prepared to do testing and reporting, I don't
> care about them because they'll eventually appear in updates.

It's about the risk of a "flaky" system you said. I use
updates-testing and kde-redhat since a long time. And i had some small
problems with it. Everything easily fixable trough a downgrade in the
worst case. And if you face a problem that hit not every user but the
package is already in stable you have to be prepared to report the
problem anyways.

>> And you can easily back out by disabling the updates-testing repo.
>
> "Backing out" means reversing an earlier advance, e.g. by using "yum
> downgrade". Disabling updates-testing won't do that. All it does is
> tread water until the standard repo catches up. Nothing wrong with that,
> but it's not "backing out".

Ok, so backing out means to revert the update trough a yum downgrade.
Where's the problem?
"Oh, i'm not convinced with the packages, so i disable updates-testing
and run yum downgrade". In the worst case grab the packages from a
mirror and run: rpm -Uhv --oldpackage

>> Nothing brakes, no problem with future updates. We're not speaking of
>> enabling rawhide for some updates. That will give you headaches at
>> some point.
>
> "breaks", not "brakes", but fair enough.

Yeah, my bad. But glad you spotted my typo. Though the truth.

-- 
LG Thomas

Dubium sapientiae initium