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

[James Antill]

On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
> James Antill wrote:
> >>  but it is the most 
> >> obvious and adding a simple mechanism to yum to report the latest update 
> >> timestamp or some repo transaction id(s) that could be fed to another 
> >> instance to ensure it ignored subsequent changes to the repo(s) to 
> >> perform an update to the same packages would be useful in its own right 
> >> and appreciated when inherited by the enterprise versions.
> > 
> >  What is this "repo. transaction ids" 
> 
> 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. 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.
 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.

> >  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.

> >  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 ... I run packages
from updates-testing all the time. And surprise, surprise, 99% of the
time they are the exact same things that end up in updates ... and the
majority of the rest of the time, they just have bugfixes for
regressions found when in updates-testing.
 If _you_ "need" to stop all updates while you test, then as I've said
multiple times ... feel free to create a local repo. based off the
upstream Fedora. This is very easy for you to do. 

> >>   Asking every 
> >> user to maintain a full repo mirror just doesn't sound like a reasonable 
> >> approach to this though, especially if you think the mirrors themselves 
> >> would have a problem storing all the updates.
> > 
> >  I'm not asking "every user" to do that. Let me show you this full
> > conversation, and hopefully it will be obvious:
> > 
> > . LES: I need to do X.
> 
> 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.

> >  We already have updates-testing and --security, --bz. Which basically
> > do this ... if you think things should stay in updates-testing longer,
> > propose some reasoning to FESCo/whatever.
> >  Making updates become updates-testing2 based on an opaque time window
> > is not the solution though, IMO.
> 
> Why is the time window opaque?

 Because you have the same object "updates" which has different
properties depending on the time, and there is no code which would
automatically let the user know that this object changes.
 For instance if you have "yum update -y" in cron. ... for this to work
with your "time window" we now need code so the user can say "apply
updates when the time window is 50% complete". Without that code the
window is opaque, maybe apart from people hanging out in f-d-l (and who
have a good memory).

>   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.

 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?

-- 
James Antill <james at fedoraproject.org>
Fedora