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
