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@xxxxxxxxxxxxxxxxx> Fedora -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
