How to make each package upgrade to save it first

[macias]

Hi,

With rolling release distro (as with LMDE) I am concerned about simple rollback. So I would like to set global (per entire system) option, that before installing any package it is copied to some directory (/packages, it is not important).

The reason: with such workflow, I could update whatever I want, and if for example the newest version of Dolphin would be worse than before I could simply go to mentioned above directory and install previous version instead (the previous version is either base version -- on ISO -- or version from previous update).

So -- is there such feature as global option to store each package before install (it have to be guaranteed, that no package is updated on-fly, i.e. without being stored before)?

Cheers,

[bobcollard]

The packages are already stored in: /var/cache/apt/archives

[randomizer]

Until you run apt-get autoclean I'm fairly sure that no packages are removed, even if they are superseded.

[macias]

Thank you very much for your help. Is there guarantee those packages will be kept (until explicit clean)? In conditions like (example) running out of disk space.

I am asking this because for rollback purpose this is essential difference, that package is probably kept <-- and --> is kept for sure 101%.

[bobcollard]

Thank you very much for your help. Is there guarantee those packages will be kept (until explicit clean)? In conditions like (example) running out of disk space.

I am asking this because for rollback purpose this is essential difference, that package is probably kept <-- and --> is kept for sure 101%.

You could backup this folder to an external drive.
Edit: There are no guarantees.

[macias]

Ok, so I have to use other way, because if there is no guarantee there is also no point in making backup (some packages could be erased between backups).

If anyone knows how to make packages stay permanently (until explicit clean), please post here.

[oOarthurOo]

http://wiki.debian.org/RollbackUpdate

Alternatively, I believe some filesystems have the ability to snapshot and rollback. You might research that, but I suspect its not a common practice yet.

[macias]

Thank you very much for the link. This approach however relies on fact, that somebody still keeps previous version in the repo. So you have to have some good luck, and be online -- which kills the purpose of rollback (how you rollback some net package, which establishes net connection).

> Alternatively, I believe some filesystems have the ability to snapshot and rollback.

I would like to not go that far.

All I need is simple rollback -- when I update something, it is stored, and that's all. Even after a year, if I need rollback, I rely totally on myself, not any third party, I simply install the package I have on disk. KISS principle at its best I think.

[bobcollard]

If you use something like sbackup and designate this folder to be backed up, the older versions will not be removed, it will backup whatever is new and leave the rest depending upon your setup. You decide what is removed, when. It is called incremental backup.

[oOarthurOo]

Thank you very much for the link. This approach however relies on fact, that somebody still keeps previous version in the repo. So you have to have some good luck, and be online -- which kills the purpose of rollback (how you rollback some net package, which establishes net connection).

> Alternatively, I believe some filesystems have the ability to snapshot and rollback.

I would like to not go that far.

All I need is simple rollback -- when I update something, it is stored, and that's all. Even after a year, if I need rollback, I rely totally on myself, not any third party, I simply install the package I have on disk. KISS principle at its best I think.

Well, I've never looked into it, because it seems inadvisable to me, but if you're committed there's two ways I'd look to first.

1. Run a cron job daily that runs an rsync job to copy any new packages from /apt/cache to your backup location.
2. Create the rsync job as above, but as a shell script. Make the last line of that script execute an aptitude update at the end then exits. Give the script an alias like "safe aptitude update" and execute that instead of the normal aptitude update.

[macias]

Thank you. I think better approach would be to patch apt-get -- add an option which guarantees no package is removed during install, even if there is no space on disk (in such case download & install fails, but the old packages are intact). Since apt-get is open-source I think amount of coding is comparable, but in this approach the result would be rock-solid.

[oOarthurOo]

Thank you. I think better approach would be to patch apt-get -- add an option which guarantees no package is removed during install, even if there is no space on disk (in such case download & install fails, but the old packages are intact). Since apt-get is open-source I think amount of coding is comparable, but in this approach the result would be rock-solid.

Ok... I'm going to assume you're just naive and not a troll.

Amount of coding / knowledge is nowhere near comparable. Amount of work to support and maintain each solution is nowhere near comparable. Lastly, I'd bet my life on rsync solution, since it is a long standing, well known, thoroughly debugged program, whereas anything you manage to produce would be an unknown quantity likely to contain bugs since you have neither a deep understanding of apt-, aptitude or, judging from your regard for which is better, much experience coding.

For myself, I'd judge the cron/rsync job to take about 1 hr of work, the pre-inst / post-inst scripts calling rsyn about 2hrs, and patching apt-get about a month following by ongoing maintainance costs unless you managed to upstream your changes. For you I'd think it'd be longer, if only because you naively believe your own patches would be without bugs and not incur ongoing costs and haven't done the minimal amount of work to see about setting up a pre-inst/post-inst rsync job.

Honestly if you're this concerned about breakage maybe Testing isn't for you. Stuff breaks. It's no big deal. You fix it. Life goes on. You don't need a separate hard-drive of backups of the installation packages. Speaking of which, try imagining coding in a test to see how many versions of say evolution there are on your backups, and deleting those more than 2 versions behind. Pretty simple with a bash script.

[macias]

> Ok... I'm going to assume you're just naive and not a troll.

Was this REALLY necessary?

> Honestly if you're this concerned about breakage maybe Testing isn't for you.

Maybe it is not, switching to stable repo is easy. I will see, and then I make my pick.

> Stuff breaks. It's no big deal. You fix it.

No, I won't and it is big deal -- I am not how-cool-is-this-new-plasma guy. I have work to do. I have my projects, and I won't fix every package which was shipped with regressions. And it is not about Stable/Testing/Unstable. It is about quality and my needs. I still use KDE3.5 because KDE4.x in my opinion is several steps back. And I bet KDE4.x is for some time in Stable repo, correct?

If you think for a bit about the info I already got from all forum members here (thank you all again) you come to conclusion, that the patch is not that hard -- because storing is already there. So such option would only prevent deleting. All it takes is -- adding an option, finding all references to cleaning the cache, and adding conditional in all places except explicit clean. That's all. Job well done, zero workarounds (I have to wait for newer LMDE though).

[bobcollard]

> (I have to wait for newer LMDE though).

This is a rolling upgrade, you do not have to wait.

[oOarthurOo]

And I bet KDE4.x is for some time in Stable repo, correct?

If you're still on KDE 3.5 you definitely should avoid rolling, testing. Try debian stable or centos.

that the patch is not that hard -- because storing is already there. So such option would only prevent deleting. All it takes is -- adding an option, finding all references to cleaning the cache, and adding conditional in all places except explicit clean. That's all. Job well done, zero workarounds

If you say so. Here's the apt source package: http://packages.debian.org/source/squeeze/apt Good luck with that.

Waiting won't do you any good because apt gets updated on Testing. You'll have to apply your patch to each new release, build and install yourself. If you don't realize this... good luck with that.

For anyone else interested in achieving this, create a script, put this in it "rsync -a source/ destination/", make "aptitude update" the last command before exit, make it executable, and give it an alias like "safe-aptitude-update". Make sure to mount "desination" in fstab if it's on a separate partition. If you already have a partition or destination in mind total time is about 10 minutes.

[macias]

> This is a rolling upgrade, you do not have to wait.

I am unable to install LMDE right now, that's why I wait.

> If you're still on KDE 3.5 you definitely should avoid rolling, testing. Try debian stable or centos.

No, no, I use openSUSE now for ~13 years, and I have enough of non-rolling distros, when you have to upgrade at some point anyway. So no, my next "upgrade" is some rolling release distro, when I won't be force to upgrade entire system ever again. LMDE looks most promising, so I'll wait for it.

The only real competitor for RR distro is PC-BSD, because of its self-contained packages (all necessary stuff is inside each package).

[randomizer]

If you are looking for the utmost stability and a rolling release then you're looking for something that probably doesn't exist. Rolling releases by their very nature compromise stability (to varying degrees) for freshness. Updates are pushed out before they have plenty of time to be thoroughly tested, but the advantage is that if something does break it can also be corrected with a shorter turnaround time than if a breakage occurred on a relatively frozen distro.

Regarding KDE versions: Squeeze, which will go Stable soon, uses KDE 4.4 by default. KDE 3.x is no longer maintained by the upstream developers. It is probably possible to use 3.5 on Squeeze, especially if you get one of the older ISOs that still used 3.5 and upgrade all packages from there except those which would force you to install 4.4.

[macias]

> If you are looking for the utmost stability and a rolling release then you're looking for something that probably doesn't exist.

Rolling release is mechanism, it does not imply the source of the data. By default LMDE uses Testing repo, but it can be switched -- to Unstable (making the system even more unstable than Testing) or Stable (making system MORE stable than Testing). Besides, rolling release does not mean you have to update anything (you can install it once, and not update anything), but IF you update, you update this or that package, not entire system (at least this is my understanding).

> Regarding KDE versions:

I will evaluate other desktop environments, for lack of eye candies and high degree of configurability. I am aware though that switching from openSUSE 11.1 (3 years old now IMHO) with KDE 3.5 to completely different system with completely different DE will be painful

Thank you for the hint with KDE3.5, there are some great programs, which newer versions didn't beat so far, like Gwenview.

[randomizer]

but IF you update, you update this or that package, not entire system (at least this is my understanding).

That's correct, providing the upgraded package doesn't require a newer version of certain dependencies than you have installed. It's much the same as a frozen release, except that frozen releases don't usually upgrade features. They release bug fixes and security patches. A frozen release typically becomes more stable as it matures, while a rolling release does not, because rather than refining what is already installed you receive packages with much larger changes more rapidly. For example, Kubuntu 10.10 will almost certainly continue to receive KDE 4.5.x updates, but will never receive KDE 4.6.x updates. Arch Linux will move to KDE 4.6 almost as soon as it is released, and 4.7 after that (assuming that 4.7 is the next major release).

So yes, while the difference between the two distribution methods is mostly the mechanism for release, there's some design philosophy differences behind it as well.

[Anixx]

I am aware though that switching from openSUSE 11.1 (3 years old now IMHO) with KDE 3.5 to completely different system with completely different DE will be painful

You can continue using OpenSUSE with KDE3. All will be OK with KDE3 repository at least for 11.4 and for the observable future. More information is here: http://en.opensuse.org/KDE3 KDE3 build status is here: https://build.opensuse.org/project/moni ... KDE%3AKDE3

It was also announced that there will be a rolling-release OpenSUSE variant soon.