Where Fedora Went Wrong (nice conclusion)

[alan]

On Tue, 15 May 2007, Alan Cox wrote:

> On Tue, 15 May 2007 12:45:54 -0400
> William Case <billlinux at rogers.com> wrote:
>
>> Hi;
>>
>> Just jumping in.
>>
>> On Tue, 2007-05-15 at 12:31 -0400, Terry Zink wrote:
>>> Another thing is that for the most part, the general consensus of Fedora by many people who don't know better but use Fedora is that Fedora is simply "beta" for Redhat.
>>>
>>> That's a stigma it has to shake, which it sadly has.
>>>
>>
>> I use Fedora because I like the thought that it is cutting edge, etc.
>> What I would like to know is: Are the contributions of users to fixing
>> Fedora picked up by other distributions and/or up the line for
>> applications?
>
> The Fedora mantra is "Upstream" so yes as much as possible everything
> gets pushed upstream to the master software project.

Reading the article I found one conclusion that was dead on.

When you do an upgrade, the upgrade goes fine, but you cannot update some 
components after that point.

I am fighting that problem on a couple of machines.

What I am seeing happening is this...

After the upgrade, you have a situation where some packages have both the 
old version and the new version of that package.  It is not all packages, 
just some.  I don't know if this is because there are dependancies that 
would break or some other condition.  When you try and do an "yum update" 
and you hit one of these "multiple version" packages, you get conflicts 
that say "package X conflicts with package X".

This problem gets worse if you have a dual arch system like x86_64 and one 
architecture has been dropped for that package.  (It gets even more 
confused.)

The only solution I have found for this is to fix them by hand when I find 
them.  This has been a problem for a long while, but yum seems to have 
gotten more sensitive to the condition.

-- 
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
                                   - Alan Cox