Keeping older packages versions in entropy [Solved]

[joost]

Not possible.

[Stupot]

The idea of the "Extra Stable" repository is basically what I am suggesting, just with different words

Eh, not quite. There is a difference between pushing packages into a new repository later than you push them into main vs always keeping a previous version of every package available.

Technically, a more stable Repo could still have the exact same packages that are in main.

The thing about a binary distribution is that all of the packages have to work together. If you decide you want to take a particular library back a version, and other packages depend on it, you could very easily be breaking many packages. With Gentoo, it's just a matter of recompiling everything, but that is exactly what we are avoiding by using binary package management. To have alternate versions of every package that would work with the previous version of every library would be impossible to maintain.

Basically, with a binary package management system, there is no going back. There is only how carefully you move forward.

[micia]

well, I was not excluding the possibility of having a previous version of every package available there, the idea was having the minimum possible for making those packages work nicely.
If there are more or less packages, it is just a matter of how that is achieved/can be achieved.

I know the difference between binary and source package management, but using other distributions, I found some of them that keep some older version of the same package, the first that comes in my mind is openSuse, so I was thinking about something similar here.

However if it is not possible, it can't be done, too bad

[alcalde]

Not possible.

Why not? Is it a limitation of the package or repository format?

[alcalde]

The idea of the "Extra Stable" repository is basically what I am suggesting, just with different words

Eh, not quite. There is a difference between pushing packages into a new repository later than you push them into main vs always keeping a previous version of every package available.

Technically, a more stable Repo could still have the exact same packages that are in main.

The thing about a binary distribution is that all of the packages have to work together. If you decide you want to take a particular library back a version, and other packages depend on it, you could very easily be breaking many packages. With Gentoo, it's just a matter of recompiling everything, but that is exactly what we are avoiding by using binary package management. To have alternate versions of every package that would work with the previous version of every library would be impossible to maintain.

Basically, with a binary package management system, there is no going back. There is only how carefully you move forward.

What I'm not getting here is this: if you decide to go back a version, you shouldn't break anything. The package manager should see this problem and then suggest downgrading the packages that depend on this library, uninstalling the package(s) that depend on the new library, cancelling the operation or breaking the dependency. There shouldn't be a need for recompiling anything... just keep the previous version of any file in the same repository.

Another idea is having a repository that contains all files for a particular release - say, Sabayon 5.5. If you ever have a major problem, you can always use the package manager to go back to the last stable release.

[alcalde]

I know the difference between binary and source package management, but using other distributions, I found some of them that keep some older version of the same package, the first that comes in my mind is openSuse, so I was thinking about something similar here.

However if it is not possible, it can't be done, too bad

I was thinking of openSUSE too, but since I've mentioned here before that I left Sabayon for openSUSE, I didn't want to seem like I was trolling. I really wish instead of saying "impossible", people would ask themselves "how can we make this possible?". Sabayon's had show-stopping updates before, and being a bleeding edge distro, will no doubt have them again. The ability to revert to a stable configuration would be a godsend, as not being able to do so could drive users away after their first bad experience.

Here's an idea - what if the package manager saved previously installed files in a directory on your hard drive and let you roll back to any of them if you so wished? That would require no respository changes at all. There could be a feature like Windows has that remembers your last known safe/stable configuration (say, the last config that let you boot up and cleanly shut down). If an update hoses the system, you could use an option to transition back to that last combination of libraries/programs/config files that worked.

Perhaps something akin to or using cfengine.... "Cfengine is a policy-based configuration management system written by Mark Burgess. It’s licensed under the GNU General Public License (GPL) and available for download from the Cfengine Web site. Cfengine uses a declarative language to define the desired end state of a system, as opposed to some other configuration management tools that define what should be done to a system.

"Cfengine actions are carried out in a convergent manner, meaning it can be run any number of times on a system in almost any state, and end up with the desired end state. You can use Cfengine to automate a variety of tasks including checking and setting file permissions, creating and deleting files, maintaining configuration files, executing scripts and commands, reverting unauthorized changes, monitoring md5 checksums, restarting daemons, and warning you about system anomalies or aberrant behavior. Best of all, it can do all this in a heterogeneous operating system environment, so it’s OK if you’re running a mixture of Linux distros or a combination of Linux and other operating systems."
http://www.linux-mag.com/id/5595/

I remember practically pleading on the forums for a feature like this after my first bad update experience. I was even asking about ways to create a snapshot of the drive so you could roll back. After the second bad update experience that involved an ATI driver problem preventing X from starting I gave up. There were all sorts of editing this and that file solutions rather than just putting the old version of the driver back in the repository to automatically fix systems for people (including those who might not have access to a second PC or know how to install a text-based browser to check the forums).

A simple way to roll back a bad update would have changed my user experience of Sabayon dramatically. I'd probably still be using it today. Maybe the theme song of Sabayon needs to be changed from Rock 'n Roll Hall Of Fame to Lennon's "Imagine". A push by Sabayon to eliminate the main drawback of bleeding edge rolling distros would be a major win and a worthy goal.

[Stupot]

What I'm not getting here is this: if you decide to go back a version, you shouldn't break anything. The package manager should see this problem and then suggest downgrading the packages that depend on this library, uninstalling the package(s) that depend on the new library, cancelling the operation or breaking the dependency. There shouldn't be a need for recompiling anything... just keep the previous version of any file in the same repository.

Another idea is having a repository that contains all files for a particular release - say, Sabayon 5.5. If you ever have a major problem, you can always use the package manager to go back to the last stable release.

I don't think you fully grasp how many inter-dependencies there are on a standard installation. The term dependency hell didn't apply to Linux package management systems of old for no reason.

You can't always just downgrade a specific package without needing to download that package's old dependencies. Perhaps it is dependent on a library that has since been upgraded 3 times. You then need that 3 versions ago library still in the repo. Then once that old library is installed, guess what? You just broke tons of other packages that also depend on that library.

As I said, it would be possible to have another repo that moves forward at a slower pace. If your system breaks, you could remove the standard repo and then switch to the slower moving repo, but rolling back a certain package could very easily cause you to install many older versions of many packages. Even then, you are still going to be at the mercy of the slower updating repo.

The best part is, this slower moving repo could easily be a community repo. There isn't any magic required, it will just take some man power and a good host (or perhaps more than just one).

As much as I (and everybody) appreciates good intentioned ideas, being able to roll back packages with a binary package management system is not a plausible task, especially not for how small the Sabayon Dev team is.

On the brightside, you already can install older versions of packages that are especially problematic thanks to portage.

[micia]

I think that the slower moving repository would already be a huge improvement, obviously it will require more mantainers and it probably is too much to ask for the Sabayon team, a community repo would be great.

But what about alcalde's idea of a backup/mirror tool in entropy?
A snapshot of your system every major update or every critical package update could be a relatively easy solution, I think that entropy is already aware of dependencies (I think it can also identify compile time dependencies), so, in a really vague fashion, you could turn on a "Safe upgrades" feature, giving to entropy its partition/support/disk space to save a backup of particular packages categories (and, thus, implicitly of their dependencies), like kernel modules or desktop session.
For example it could mark "gnome-session" as a "Desktop Session Package", as entropy detects an update to that package it will prompt you saying "Entropy detected a Desktop Session update, would you like to backup your current packages?".
If yes it will backup all your packages, dependencies, etc.. For that category and you can revert your installation if something goes wrong.
Disk space, updgrade time, everything is user's own business
So the Sabayon team will be not involved (except for the developers that should write it, aka lxnay I guess )

I think that marking packages in such a way could be used in other circumstances, for instance, in order to suggest reboots for current kernel modules updates or for X Server restarts during updates in the current Desktop Environment packages (for example updating KDE4 when you are in a KDE4 session).

Reading about that Cfengine thing is also very interesting, I wonder if it could be useful for this purpose.

[alcalde]

I did some checking and the old openSUSE package manager before zypper had these features:

* Add a checkpoint to the package system for later rollback

* Remove a checkpoint from the system

* Provide a list of all system checkpoints

* Rolls entire packages back to a certain date or checkpoint.

This sounds like exactly the type of thing micia and I are talking about. From how I understand it, you could create a checkpoint before doing an update, then I assume any files that got changed/replaced/deleted from then on would be backed up. Rolling back to a checkpoint would undo all of those changes, and deleting a checkpoint would remove all of those cached files. This process wouldn't have required any repository support and I think it wouldn't even need much change to the existing package manager. No one uses it, but equo has features like being able to take a package and produce a tar zip file of all of the files of that package with proper file heirarchy in the archive. This could be done on an existing package before it's updated for instance and you get a nice tgz backup already. In that sense, a lot of the work already exists in entropy/equo (and I'm not sure what reason such a feature would be in there except for an idea like this).

[Fitzcarraldo]

RPM used to have a package rollback feature: see the May 2004 Linux Journal article Transactions and Rollback with RPM. The only trouble was: it didn't always work (see e.g. Qs on RPM Rollbacks) and was subsequently dropped. If it was simple to do, all the package managers would do it.

Support for repackage and rollback have been removed as they're seen too unreliable to be generally useful.

If the major Linux distributions, with all their resources (including many paid developers), cannot produce a reliable package rollback function, then it can't be in the least bit easy.

I think a more viable solution in the case of Linux is the use of a file system that supports snapshots. When Btrfs finally replaces ext4 as the main Linux file system this could become a possibility, providing the creation and restoration of snapshots can be made simple enough for the average user to perform.