On Tue, 2008-12-09 at 15:50 -0600, Les Mikesell wrote: > James Antill wrote: > > On Tue, 2008-12-09 at 09:43 -0900, Jeff Spaleta wrote: > >> On Tue, Dec 9, 2008 at 9:33 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > >>> But, as I've mentioned before, I think you'd get much better public > >>> participation in testing if yum could do repeatable updates. That is, I'm > >>> only interested in testing exactly the update that I will later do on my own > >>> more critical machine(s) and I'm not interested enough to maintain my own > >>> mirrored repository which is currently the only way to get exactly the same > >>> set of programs installed on 2 different machines at different times. > >> Do you mean.... we require all the mirrors to hold all version of all > >> updates for a release cycle? > > > > Yes, that's the only sane way to do it. yum-debug-dump / > > yum-debug-restore will somewhat do the above, if the repo. has the old > > versions available. > > I don't think that's the only sane way to do it, And yet you haven't illuminated what those other sane ways are. > 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" ... how is that different from a local mirror. Even better question how is it _better_. 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). > > However Fedora only has the latest, so the only real > > alternative is creating a new repo. of somekind ... at which point you > > might as well just do a local mirror. > > Fedora has this split personality about wanting to be both > production-usable and also the leading edge where new code first meets a > lot of new situations. You can't quite be both at once. Those features are not binary flags, they are a line with RHEL-2.1/CentOS-2.1 on one end and rawhide on the other. There are a lot of points on that line and Fedora serves some of them well. > However, it > could actually pull it off if there were a way designed in to avoid some > of the bugs pushed out in updates on critical machines. 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. > 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. . JAMES: To do X you need a local repo. . LES: Asking every user to maintain a local repo. isn't reasonable. > It could be as simple as batching updates: suppose everything but > critical security fixes and corrections for known-bad updates only > updated every few weeks, and the user could could choose (with a > permanent option) whether any particular machine should update on the > leading or trailing edge of this window. 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. > Or, pick a time frame reasonable both for mirrors to hold updates and > for users to complete testing (2 months?) and only remove packages after > their replacements have reached that age. Have you spoken to anyone about how much data that would be, and how much the mirror admins would like/want it? This is the fundamental problem with keeping all the data for old updates ... the mirror admins don't want to commit. If you have a local need for it though, you can presumably afford the resources. > Or, what if one machine's yum automatically acted as a proxy for > another's update, perhaps with an error generated if the package hadn't > been downloaded already and if you want to be even more helpful, a > warning if none of the code from a package had been run on the > intermediate machine? You want a specific collection of packages to be exported for other yum clients to use ... we have this, it's called a repo. > That way you'd get local mirroring of just the > desired packages without extra work anywhere - in fact you'd get both > repeatable updates and a load reduction on the mirrors out of it. A mirror that is different from it's upstream repo. _isn't a mirror_. Yes, you can create a local repo. using data from a remote repo. as it's basis ... but unless it's identical (within a limited timeframe) then it isn't a mirror. > It's > probably possible to do this now with a lot of extra steps. Nobody is > going to do it unless it is one step and looks like a cleverly planned > design. It kinda works right now, with Fedora, because Fedora doesn't sign the repomd.xml or use metalinks to validate the repomd.xml ... both of those things will change in Fedora 11 (and metalinks can be used now). At which point yum will reject a mirror which isn't. > Or, design a working solution to back out broken changes. The only one > I'd trust would be to install with a spare system partition that is > synchronized with the active one just before an update and used as an > alternate boot for a fairly drastic fail-back mechanism. And even that > won't work where file formats of things in other partitions are modified > in an update. Yeh, good luck with that, but it's far from a yum problem if you want to follow that route. -- James Antill <james@xxxxxxxxxxxxxxxxx> Fedora -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
