I realize this doesn't address the concern about not pushing broken updates to begin with. However, if yum and/or rpm could do a downgrade from locally cached delta, it would make reverting the change that broke the system much easier. This obviously won't work if it's rpm that breaks, but that is typically a Rawhide problem.
If there's a magic solution that will satisfy the vast majority of Fedora users, I have absolutely no clue as to what it might be.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/10/2010 08:26 PM, Steven I Usdansky wrote:
If there's a magic solution that will satisfy the vast majority of Fedora users, I have absolutely no clue as to what it might be.
Please read: http://nixos.org/nix/ Esp. "Atomic upgrades and rollbacks"
- -- Alexander Kahl GNU/Linux Software Developer
Alexander Kahl wrote:
On 03/10/2010 08:26 PM, Steven I Usdansky wrote:
If there's a magic solution that will satisfy the vast majority of Fedora users, I have absolutely no clue as to what it might be.
Please read: http://nixos.org/nix/ Esp. "Atomic upgrades and rollbacks"
That's not a solution for Fedora at all. It's a completely different package manager (competing with RPM). It also works by keeping all the old versions of all packages stored on disk all the time, a massive waste of disk space, and also not compliant with the FHS (Filesystem Hierarchy Standard).
Kevin Kofler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/11/2010 02:16 PM, Kevin Kofler wrote:
Alexander Kahl wrote:
On 03/10/2010 08:26 PM, Steven I Usdansky wrote:
If there's a magic solution that will satisfy the vast majority of Fedora users, I have absolutely no clue as to what it might be.
Please read: http://nixos.org/nix/ Esp. "Atomic upgrades and rollbacks"
That's not a solution for Fedora at all. It's a completely different package manager (competing with RPM).
Well, now that you mention it..! ;)
It also works by keeping all the old versions of all packages stored on disk all the time, a massive waste of disk space,
Please define "massive" if you're keeping exactly what's needed to keep everything running and prune anything else by using a sophisticated, tunable garbage collection mechanism.
and also not compliant with the FHS (Filesystem Hierarchy Standard).
Yep. It's much better, comparable to the GAC (global assembly cache) of the CLR (Mono), just applied as a packaging / filesystem layout paradigm for the whole system. Please read my other post in reply to yersinia - sorry, this thread is cluttered, bad MUAs.
- -- Alexander Kahl GNU/Linux Software Developer
Alexander Kahl wrote:
Please define "massive" if you're keeping exactly what's needed to keep everything running and prune anything else by using a sophisticated, tunable garbage collection mechanism.
The whole point of the exercise was to do a lot of updates. But the more updates we do, the more disk space the old versions you're keeping around are going to eat up.
and also not compliant with the FHS (Filesystem Hierarchy Standard).
Yep. It's much better, comparable to the GAC (global assembly cache) of the CLR (Mono),
Yuck! Do you seriously call that "better"?
Anyway, the FHS is not really negotiable.
Kevin Kofler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/11/2010 11:54 PM, Kevin Kofler wrote:
Alexander Kahl wrote:
Please define "massive" if you're keeping exactly what's needed to keep everything running and prune anything else by using a sophisticated, tunable garbage collection mechanism.
The whole point of the exercise was to do a lot of updates. But the more updates we do, the more disk space the old versions you're keeping around are going to eat up.
Again, this is where garbage collection kicks in. For any kind of rollback system save from "guessing" the old state you'll need some kind of recording. Nix' mechanism eats much fewer resources than e.g. complete filesystem snapshots.
and also not compliant with the FHS (Filesystem Hierarchy Standard).
Yep. It's much better, comparable to the GAC (global assembly cache) of the CLR (Mono),
Yuck! Do you seriously call that "better"?
Do you actually know the GAC, i.e. have you ever worked with it?
Anyway, the FHS is not really negotiable.
Luckily the whole LSB is negotiable, else we'd still be sticking to this horrible, ancient SysV init system.
- -- Alexander Kahl GNU/Linux Software Developer