On Tue, 2008-11-25 at 19:42 -0300, Horst H. von Brand wrote: > Callum Lerwick <seg@xxxxxxxxxx> wrote: > > On Thu, 2008-11-20 at 04:33 +0100, Ralf Corsepius wrote: > > > > Let me point out that rollback itself would require testing. > > > Quite do-able. See my reply to Jeff. > > > > Let me point out that package rollbacks will never work in general, > > > because updates may contain non-reversable state-full operations (e.g. > > > reformatting databases). > > > So, only do such updates in distribution upgrades. > > How do you find out if something in a %pre or %post, or even in the package > installation itself, is impossible to undo? Sure, you can require it > doesn't happen, but mistakes are a fact of life... Which is why I proposed automated regression tests, which would catch this. I'm not sure what you're arguing here. You can always rpm -e a package, last I checked that was always a valid use case. Thus reversal of what a package install does is already expected to happen. Nothing here has changed. This is what is driving me nuts. If rpm -e of a package is always valid, that means you can always rpm -e any package then install an older version. Thus rollback is fundamentally possible. Seriously, what about this is so hard to comprehend? > > Something I'm regretting to note earlier, is that I do not expect the > > per-package rollback mechanism to work across distribution releases. > > It's intended for updates inside releases only. > > Great. Get users hooked on "if it breaks, just roll back" and then leave > them out in the cold when they will most likely have a need for it. Yeah, because "My system broke, fuck this shit I'm going back to Vista" is so much better. I'm talking about making something people *already* do by hand, automated and painless. If something really essential breaks, like your X drivers or kernel, do you really just sit there with a useless broken system and wait for it to get fixed? Or do you boot the old kernel, boot in run level 3, rpm -e the new X drivers and reinstall the old ones? (Then file a bug report...) How are you even going to file a bug report with a broken system? Not everyone has ten computers in their house. I don't know about you, but I have shit to do, I can't afford to sit and wait for someone else to fix it. > > IMHO I think discrete releases are one of our most powerful features. We > > can make drastic changes across the distribution, in an atomic manner. > > It has /never/ been "atomic". Are you just being contrary for the fun of it? How is an officially sanctioned anaconda distribution upgrade not an atomic operation, from the perspective of an RPM transaction? > > We want to preserve this feature. It allows us to make a clean break > > with previous releases. It allows us to make irreversible changes. > > Right. ^_^
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
