I know how to do it with synaptic, I know how to do it with apt-get, but the problem is, apt-get and synaptic want to remove about 100 packages! I cannot allow this to happen, because reinstalling them all will take ages and cause major file system fragmentation (and it works so fast with e4rat).

There is a way. Use dpkg -i /var/cache/apt/archive/package-name-and-version.deb. It CAN downgrade a package without ruining the system. Why the stupid apt can't?

And another problem. If I don't have the package, I have to manually download it. It's so lame. The apt-get install -d doesn't do what it supposed to do. It wants to REMOVE packages before downloading. Is there a way without removing? Damn! It's like Monty Python, I can have any haircut I want, but after spilling boiling water on my head!

The package I installed didn't change other packages, it's a single stupid package which will totally work when installed with dpkg.

If someone solved this issue, it would make testing experimental packages way easier.

BTW, it's always gnome. Any shared library used by gnome cannot be downgraded without stupid apt trying to remove all gnome files. It's obvious - it first try to remove the package and since it's required for 100 other packages, it tries to remove them too. THEN it finally installs required package. It's so damn wrong! This behavior occurs only when trying to downgrade a package. Upgrade works as expected, no removing part.

PS: After manually downgrading packages with dpkg, they sometimes need to be reinstalled with apt-get. Their dependencies too.

As an option. I know I have to manually satisfy all package's dependencies, but it seams illogical to remove packages to which downgraded package is a dependency. If those packages require newer version it would make sense. But the problem is - they don't. Let's try to replace libglib2.0 with the one from experimental repo. The package itself has very few dependencies. Let's say we replaced 3 files. And now we immediately try to take it back. Apt will try to remove 130 packages depending on perfectly correct package version you are installing. I think it's wrong.A right automated tool would make alpha testers life a lot easier. Maybe it would even speed up Debian development.

This would be right if I use my machine for testing only. But it's not the case. I use this machine to do actual work. I test new packages only in case I miss a feature or experience a bug in latest stable version. So far it works great, but downgrading is very time consuming.

I think I'll have to make the automated tool for it myself. So - it won't happen in nearest future - too much work.

My point is - Ubuntu/Mint is for everyone. Debian/LMDE is for power users. Power users should test new features. And yes we can But a little automation to this process would be nice feature for LMDE.

If not a dedicated alpha tester, but actual power user would test the latest available packages - it could be useful to whole Debian community. I mean tests in everyday work, and in the quickest possible way. I described with details where the problem with downgrading is. Instead of testing for removal of a package for downgrade, the same scenario as for upgrade should be used. No removal test for dependency test.

HTD's idea for easing the pain of downgrading a package is great. I just ran into this problem last night. I wanted to test out an experimental build of an application to see if it supported my hardware yet (it didn't). It required a newer libc6 package, so I installed the unstable experimental version, which upgraded about four other packages as well. Now I am faced with a mountain of work to downgrade the libc6 package and go back to the stable version. Upgrade was smooth, but downgrade via Synaptic wants to uninstall a massive number of other packages. Some of them seem to be pretty important. This is not helpful, and creates a real disincentive to try out new things. After the new experimental package is removed, then all other dependencies would still be satisfied if I returned libc6 to its previous version.

HTD (or anyone else), I'm still fairly new to the Linux world, but I am capable of tinkering around. If you are still interested in developing an automated downgrade tool, I'd be interested in contributing some time to work on it.

semog wrote:I wanted to test out an experimental build of an application

So don't expect it will do well with regular packages already installed and coming from standard official repos of your distrib. Experimental is that: something that can irreversibly wreck your current installation.

So don't expect it will do well with regular packages already installed

I fully understand the ramifications of running with experimental packages. However, that doesn't mean that removing them once the experiment is complete should be so difficult. Better tools for removing or downgrading packages need to be developed. The same thing can happen with packages that are not experimental. What qualifies as experimental is entirely relative.