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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux