| |||||||||||||
Another day, another package managerAnother day, another package managerPosted Nov 26, 2012 14:12 UTC (Mon) by vonbrand (subscriber, #4458)In reply to: Another day, another package manager by man_ls Parent article: GNU Guix launches
Please explain how "transactional updates" and "rollbacks" are suposed to work. Sure, in complete absence of bugs and requirements to tweak changed configuration files, they are easy. But (as always), practice is mighty different from theory. They aren't in mainstream package tools (APT, RPM), and not for lack of imagination by their authors.
(Log in to post comments)
Another day, another package manager Posted Nov 26, 2012 15:08 UTC (Mon) by man_ls (subscriber, #15091) [Link] Precisely: as practice is different from theory we need someone to do a real implementation, so they can shake out the bugs and identify the weak spots. Then the required work can be done on mainstream package managers.It is not lack of imagination, but lack of experience what usually holds down improvements. I imagine that transactional databases were also seen as impractical at some point, but are now easy to implement.
Another day, another package manager Posted Nov 26, 2012 17:48 UTC (Mon) by vonbrand (subscriber, #4458) [Link] My point being that it has been considered (and tried) many, many times over; the real-world benefits turn out to be very scanty, while the difficulties in getting it really right are humongous. I.e., it just isn't worth doing.
Another day, another package manager Posted Nov 26, 2012 17:58 UTC (Mon) by man_ls (subscriber, #15091) [Link] You asked me to explain how it is supposed to work. Well, the use case is easy to explain:
Another day, another package manager Posted Nov 26, 2012 20:40 UTC (Mon) by vonbrand (subscriber, #4458) [Link] The real scenario is more like "System works fine (at least it looks that way), user updates something, does random stuff, screws around with some configuration, after boot something is now broken." Roll back what? The update? Which of the 200 package updates since last boot? The configuration change(s)? The changes in other, perhaps (or not) related data? Local configuration in the user's account? As I said, it is definitely never that simple.
Not the cure for cancer Posted Nov 26, 2012 21:23 UTC (Mon) by man_ls (subscriber, #15091) [Link] Way to be positive, man! At least with a transactional package manager you can roll back the 200 package updates since last boot and discard that factor. Or confirm it; and in that case you can even bisect which package update caused the wreckage.And yes, before you say anything: a transactional package manager will not protect you if robbers come to your house or the CIA confiscates your hard drive or a lightning disintegrates the sodding computer. It is a limited tool with limited uses, which savvy administrators can use to their advantage.
Another day, another package manager Posted Nov 26, 2012 22:16 UTC (Mon) by zlynx (subscriber, #2285) [Link]
I think filesystem checkpointing is probably the only real way to do this.
Doing it in the package manager is only coming up with a weak version of it anyway.
Package systems that attempt it need to do things such as track file changes made in scripts. It is much easier to let the filesystem do this for you.
To make a completely reliable system, it probably needs filesystems for / and /usr; /etc; /home/$USER/.local. That way, to solve a problem you can roll back individually the binary executable files, the system configuration files and the user's configuration files.
Btrfs subvolumes seem to work really well for this.
Another day, another package manager Posted Nov 27, 2012 11:37 UTC (Tue) by hummassa (subscriber, #307) [Link]
Filesystem checkpointing has the disadvantage that takes your data away with it (unless you do it in a very contrived way so you can separate what is "user configuration" from what is "user data")...
|
|||||||||||||