Keeping older packages versions in entropy [Solved]

[micia]

Hi,

I am using entropy since I first used Sabayon, I have to say that it is one of the easiest to use package manager out there and it does its job fine, however I think it would be a good idea to keep some older version of the same package, at least for the most important ones (like Gnome, KDE, XServer...).

For example, I upgraded recently to KDE4.6 and I noticed some kind of instability in the new integration with udisks, some strange behavior with Desktop icons and such.
Honestly, if I had the possibility to downgrade it to KDE4.5 and wait until the next version of KDE4.6, I would have done it.
It could help also for the stability aspect of Sabayon: if the new version does not work, you can always put the old version back

Maybe, in order to save bandwith, those packages could be in a separate server with limited bandwith, I don't know the details and technical aspects... But this is just an idea

[Stupot]

We shouldn't be running into these stability issues. This is why we have a testing repository to testing everything out first. Unfortunately, even with testing things first, some things still get rushed every once in a while and testers are busy people as well.

[micia]

Of course it should not happen, but since it is hard to ensure the stability of a new software, even testing it without rushing things (especially if the distro is bleeding edge, like Sabayon is), I think it could be a good idea, if feasible.

Sabayon has grown a lot in stability. It is generally very stable, however you can always find a problematic software, so having that "fallback" would be nice.

[wolfden]

yea KDE 4.6.0 kinda got put into main by accident, not our way of doing things traditionally. Life happens I guess. Maintaining multiple version of a DE could get to be a headache for entropy team. A simple flag change and your rebuilding KDE several times. I could see a last rites repo for packages. Once entropy team bumps main, packages bumped could go to last rites repo and be available for certain period of time. The packages in last rites wouldn't get any maintenance, a use at your own risk type of thing. I just don't know how practicable that is.

limbo = packages need testing
|
main = current stable packages
|
last_rites = gonna be deleted forever

[raman]

I think it's good idea for ppl which want use Sabayon to nice, stable work. Some ppl and I know a few want use Sab to server things and the stability it's very important to them. They love Sabayon and dont really want use anothers stable distros like Debian, etc. So maybe indeed create some stable branch and keep it on repo to time, when a standard branch will be moved to stable branch when limbo branch will be shifted.
I think it's very good idea.

[timothyRlamora]

I think it is a good idea to, but we also have forums that we can report any problems and once reported it usually will be fixed soon. We have to learn to be patient, this is the idea of having a rolling release so you don't have to download and burn a new cd-dvd to get the new version, just keep up with the updates and you have the newest version, sure there are going to be bumps along the way but if we help each other out things should proceed smoothly.

[micia]

@timothyRlamora

My idea is not to limit the rolling release capability of Sabayon, in my opinion it is one of the best features, I was only thinking about something like this:

Code: Select all

equo update
#woah, there is a new version of program "foo"
equo install foo
#let's see how it is
foo
#SIGSEGV, Demons fly from your nose, the CPU leaves the PC
#uhmmm, the previous version worked waaaay better
equo mask foo-updated.version
equo install foo


so, if you run a equo upgrade, you will pull the latest version, as you do today, but if you want, you can downgrade the package to have the old version, for whatever reason, bugs, reliability, regressions, politics...

The last rites repo sounds like what I am thinking, obviously there should be no expectation for updates/support for the old packages, since they should reflect "the old version", if it worked before, it will work with a reinstall (I think entropy is able to deal with dependencies and such).
The packages could be available in the repo for a period of time that is proportional to the problems reported in the forums.

For example:
* package A gets updated to B
* there is no complaining in the forums and no Bug reports about B
* we will keep A in the last rites repos just until B version 2 is released, when B will go to the last rites
as opposed to:
* package A gets updated to B
* there are Bug reports and lots of complaining for B
* we will keep A in the last rites repos until there is a version of B that is known to be stable

In my opinion, this should be done just for critical packages, like kernel (as entropy already does), X server, main DE, packages like HAL, udisks, upower...
Not for every program in entropy, which would be too hard to handle.

[timothyRlamora]

T o bad we couldn't come up with our own version of system restore like windows, that if you run into probs you could revert to your original settings

[Stupot]

The big problem with keeping the last version of a package is dependencies.

It is hard enough to keep all of the dependencies for all of the latest versions of packages. It would near impossible to keep track of all of the dependencies of previous versions of applications.

For instance, with KDE 4.6, we've already had a couple of packages with revision bumps. Do we keep the most previous revision bump in this previous repo/last rite? If so, then we won't have all the packages for KDE 4.5.x. Previous versions of packages have dependencies too, and they might not be what is currently installed. Figuring out everything that needs to be kept just to keep the previous version of every package could easily be a nightmare.

In my opinion, I think an easier solution would be to add a QA repo in between testing and main. (Limbo -> QA -> Main) There are lots of things being tested in the limbo repository all the time and not everybody feels up for signing up for that. However, most people don't mind what little amount of issues we run into right now. Those people would want to get the QA repos. That would keep things being pushed to the main repos until after many more people have tested it.

Or perhaps another way of looking at it would be to have an Extremely Stable Repo after main. (Limbo -> Main -> Stable Xtreme!)

The way to set it up sort of depends on what most of the users want. If most users are happy with how things are, then we would want main (and all of its mirrors) to stay the same. Then we could add the Stablest Repo which could get things after main and people who are extremely concerned could stick with that one.

[micia]

I agree that dependencies are a bad thing to handle, but entropy can resolve dependencies quite well, most packages specify the lowest version and the highest version for a package dependency, I don't know if entropy does the same.
I'd say to keep the highest one for those.

The idea of the "Extra Stable" repository is basically what I am suggesting, just with different words
A repository where packages that are known to work can be found, even if they are not the most up to date, since I think that it could be difficult to find enough space and bandwidth in the servers and mirrors (since it is expensive and the Sabayon team needs food), I was stating that it could be done with a subset of the current Sabayon softwares, eventually limiting the bandwidth for those repositories, considering that the most requested software is supposed to be the latest.
You can call it "Extra Stable", "Last rites" or anything, but it is the main idea.

Since I have no deep knowledge of entropy, of the repository architecture, or about the impact that this could have on the expenses and man power needed, I can't suggest any explicit way of doing it...
I am just suggesting an idea that I would find nice to expand the user base of Sabayon and probably its stability.