[Testing - Trixie] [Solved] Downgrading to stable with t64 packages

[Outline]

Hello, I recently upgraded to testing and just discovered that security updates arrive delayed to testing. Overall, I would prefer to come back to stable.

I have a btrfs setup with automatic snapshots but for some reason the last snapshot I have from stable is not booting properly, so I'm not sure about using it.

When doing the downgrade, I receive many dependency break due to t64 packages that have different names in testing compared to stable. I can fix some of them (e.g. I managed to downgrade apt) but doing it for all the t64 packages is tedious.

Is there any way to properly downgrade now that packages have different names (e.g. perform the upgrade even if the dependencies are broken and then fix the dependencies later)?

[wizard10000]

I'm afraid there is no supported process to downgrade packages in Debian.

If your PC is working correctly now my suggestion is to switch sources back to Bookworm and just continue to use it. You may or may not have issues in the future but most likely will be okay if it's working now as Stable isn't gonna get much except for security updates.

Another option if you're concerned about timely security updates would be to run Unstable but that will bring its own challenges. I've run Sid for a bunch of years but it does require close attention to what your package manager wants to do to your system

[Outline]

Thanks, for your support.
I know that downgrade is not supported.

I was just wondering if there is a way to mark all the packages containing "t64" to uninstall and all the same packages without "t64" to install.
I'm using aptitude to solve the dependencies, but I can't find a way to do this efficiently.
It would be enough and I could then solve the other dependencies manually...

[wizard10000]

...I was just wondering if there is a way to mark all the packages containing "t64" to uninstall and all the same packages without "t64" to install.

I wasn't in on the project but I do know from being an end user we're talking about hundreds of packages, enough that aptitude started getting crazy until I did a full-upgrade.

I really don't know the effect of removing hundreds of packages but I imagine the breakage would probably be catastrophic. Afraid I can't recommend it.

[CwF]

I have done a few downgrade surgeries and always use synaptic. Anymore, if not manageable by synaptic, I'm not involved.

With the repos straightened out all the sid packages will be listed with 0B download size and therefor easily grouped by that column, if download size is configured as a column.

Usually I have found that the logic order should be Install before Remove/Purge. Using the column sort you should be able to identify the packages to install and simply test the reaction to any install attempts. Just stay away from removing anything prior to having its replacement already in the cue. This way any long nasty dependency chain list will be corrected prior to their generation - if that makes sense...

Don't be afraid to click around without applying changes. You can clear all selections and start over as often as you'd like. It's a learning exercise first! If no path seems possible, there's the answer.

[Bulkley]

For the future, before doing a major upgrade, such as from Stable to Testing, I clone my hard drive to a spare I keep for the purpose. When things go haywire it is easy to recover.

[Uptorn]

Ride it out until Trixie enters freeze. <- lazy way

Gather ~/home/ into the ark while you raze the Trixified landscape with a fresh Bookworm flood. <- not so lazy way

[Outline]

For the future, before doing a major upgrade, such as from Stable to Testing, I clone my hard drive to a spare I keep for the purpose. When things go haywire it is easy to recover.

Actually, I have btrfs snapshots and I think they would have worked but there were errors with the kernel modules and I didn't want to risk.

I solved the problem though. Here is the script I used: https://gist.github.com/00sapo/5cc2db57 ... 2c22ef6c5e
It automatically finds mismatching packages and analyzed apt policies to decide which package should be kept.
Actually, I think it could be done better if only I knew how to select a specific version of a package, instead of only indicating the package name.

After having run the script, the dependency resolution was solved, but the upgrade stopped because dash removal scripts require libc 2.38, but it was already downgraded by apt. I solved by temporarily changing `/bin/sh` and `/bin/dash` with symlinks to `/bin/bash` and installing dash via `dpkg -i`

However, since the upgrade stopped, several things were remained unsatisfied. Ineeded to run:
- `apt -f install`
- `apt dist-upgrade`
- `aptitude full-upgrade`
- `apt reinstall sddm libqt6gui6 libqt5gui5`

Finally, sddm themes were unexplicably disappeared and I needed to reinstall them.