Restore-Points in Gentoo Linux

Today I was very tempted to upgrade my Gnome desktop to version 2.20, which is in the Portage tree, but not yet marked stable. Then I thought to myself - remember what happened the last time you attempted something like this? I spent the entire day simply trying to figure out which packages to downgrade.

Gentoo's Portage package management system is excellent because of the fine-grained control provided to the administrator over which packages and which options (USE flags) are installed. Again, on the plus side, a local repository of binary packages can be created (with FEATURES=buildpkg) so that packages need only to be compiled from source at least once. I write 'at least once' is because a package will need to be recompiled whenever a version number changes (obviously) or whenever the USE flags are changed. None of us really like that, but it's a fact of life.

Now, taking a slightly deeper perspective into the concept of a local repository, there are a few different ways of organizing this. If you think of all of the variables involved with the instantaneous state of a portage-based system, ignoring overlays for now, the collection of all installed packages becomes a (lengthy) one-dimensional 'tuple' at any particular point in time.

Now, lets say that each binary package stores all of its dependency and USE flags when it is created. Then, theoretically, we could do a complete re-installation of all of the packages on a system with the binary packages alone.

In this repository, for the sake of sparing disk-space, we would likely just dump unique binary packages in a position that would be written down in a massive table. From the simplest perspective, we could simply duplicate the entire table (actually, a look up table) whenever a package or USE flag had changed.

That would probably end up being a horribly inefficient waste of space. But on the completely opposite end of the spectrum, if one was to account for each package, and create variable, off-shooting dimensions of each tuple element whenever a new version was introduced, or when a USE flag was changed,

When a USE flag is changed, then so do the dimensions of each of the elements in those tuples. In fact, what we would observe is a hyper-volume of data pointers where each element is of varying dimension and size. If one was to attempt to visualize this, it would look something like a fractal hyper-image, where the residuals of each change dieing off after some amount of forking.

The obvious trade-off is complexity versus storage space... although, think since this repository would only be storing tuples of locations on disk, then the storage space might not be so high. Although, the size of the hyper-volume would increase exponentially with each new package added. On the other hand, the 'fractal' approach would be much harder to navigate (there might be some way to organize it in a hashing system). I'm not sure if it would be faster or slower.

In any event, one would need to call a tuple out of this repository and then re-install the binary files. The recorded tuple would then be a restore point.