Another day, another package manager [LWN.net]

Another day, another package manager

Posted Nov 26, 2012 17:48 UTC (Mon) by vonbrand (subscriber, #4458)
In reply to: Another day, another package manager by man_ls
Parent article: GNU Guix launches

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.

(Log in to post comments)

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:

The system works fine.
User upgrades a set of packages.
The system does not work anymore.
User wants to roll back to state 1.

Given that there is a real need to do this sort of thing, and that people are resorting to filesystem-checkpointing to get it done, I think it is worthwhile to try it again. Also, apparently this is a solved problem with nix so the GNU project is not experimenting, just giving the solution a real-world framework.

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")...