What Fedora makes sucking for me - or why I am NOT Fedora

[Les Mikesell]

James Antill wrote:

>> If you tracked changes in a repo, yum could use that to ensure that it 
>> didn't pull newer packages when you were trying to reproduce a tested 
>> update.
> 
>  Or, without re-writting the entire world ... it could just use the
> NEVRA information that is already there.
> 
>> ... how is that different from a
>>> local mirror. Even better question how is it _better_.
>> Ummm, it saves every user a boatload of work and disk space... More to 
>> the point it is something that they might actually do.
> 
>  Again, transaction ids are just a way of saying "turn a yum repo. into
> a git repo. ... with branches etc." ... but doing that it _still_
> requires the "old" packages, which we don't have.

So, what is the correct plan to avoid getting a broken update onto a 
machine you care about?  Take the one towards the end of FC6 that broke 
machines with certain SCSI adapters as an example.  It was quickly fixed 
but it ruined my day and finalized my opinion of fedora. I'm not 
planning to use fedora again until I see some reason to think that won't 
be repeated.

> And if we did have
> them, then we don't need to integrate git functionality into yum to get
> the behaviour of being able to install older tested packages.

OK, repeatable yum updates would work. Can you maintain an archive 
somewhere?

>  The advantage of a local repo. (with an upstream source) is that you
> have to do minimal work, and you can control when the data changes.

First, maintaining my own repo mirror, _and_ a test machine is just too 
much work to avoid breakage that shouldn't be present anyway, and even 
if I did that, how do you propose that I get the snapshot I want into my 
repository if it changes all the time?  What if I miss the update 
version I really wanted?

>>>  Everyone who spends five minutes thinking about it comes up with "I
>>> know we'll merge the functionality of git and yum, so that you can
>>> follow branches in a repo. etc." ... which _might_ be fine, if _they'd_
>>> actually have to implement it. But I fail to see the significant
>>> advantages over doing all of this work on the repo. side (and possibly
>>> creating tools there, to help -- again, feel free to if you want this).
>> Yes, it is clear that you need version control capability in a package 
>> manager.
> 
>  No, it isn't.

Well someone has to do it.

>>>  By "avoid some of the bugs" I'm going to assume you mean "I want other
>>> people to do work" ... which is nice, but not how it works.
>> No, I have said I would do much more testing if given a design where I 
>> knew I could subsequently update a working machine to exactly the same 
>> set of packages I had tested.  I'm just not willing to mirror a whole 
>> repository to deal with this on my own.
> 
>  Again, other people don't need this extra behaviour ...

What percentage of the world's computers run fedora? .01%?  I'd argue 
that nearly all "other people" need stability fedora doesn't deliver.

>> You misunderstood.  I'm not prepared to be the only tester. I mean "if 
>> you do X, many more people will test".  Basically everyone who runs 
>> fedora needs to do X unless they can afford to be down a while.
> 
>  Again, there are people testing already ... I run many updates from
> updates-testing. What you desire is not required to test things from
> updates-testing.

Can you guarantee that what happened at the end of FC6 won't happen 
again?  If I had a duplicate machine just for testing, what interval of 
updates/tests would I have had to run to have caught and noticed the 
broken update in FC6?  What procedure would I have followed to be sure 
it didn't hit my working system?

>>   Again, why do you expect anyone to test, 
>> whether from updates-testing or elsewhere without a mechanism to use 
>> exactly the package set that they tested on their working machines?
> 
>  Because most people don't need that feature to test, they trust that
> the package owners aren't going to put X-1 into updates-testing and then
> quickly put X-666 into updates, which is completely different, when
> noone is looking.
>  In the _vast_ majority of cases this trust is not misplaced.

If I didn't care whether my machine worked or not, such a sweeping 
generality might sound nice.  But, can you tell me you are certain a 
fedora update will never break something I need to have working again? 
And if not, will you at least admit the need for a mechanism to improve 
that? "Trust" just doesn't trump experience...  And this thread wouldn't 
exist if my experience was unique.

>  As many other people have already told you, many times. If you don't
> trust Fedora, aren't prepared to help test it and think that it isn't
> tested enough for your use ... why don't you just use CentOS/whatever?

As I've said, I'm not willing to test configurations that are 
reproducible because I don't think that makes any sense, and I'm not 
going to maintain my own mirrors of many arbitrary snapshots of a 
rolling repository hoping that sometime I'll catch a good one.

Basically I do use Centos, but didn't someone say that some of the new 
code is useful? I'd like to be able to try it...  As you've pointed out, 
it is 'mostly' usable, but I won't use it until there is some reason to 
think I can avoid the small number of mistakes that happen on the 
machines I care about.

-- 
   Les Mikesell
     lesmikesell at gmail.com