After upgrading to a new version of KDE with a small bug, I would have loked to
return back to previous version. Howeever the upgrade was ~ 400 pacakges and
that makes it complicated, getting all packages in the logs.  So I thought of
the 1 feature I miss from yum in apt : the possibility, after an upgrade to
rollback to the previous versions of package list That would be a good feature
for apt

(generally) not work. Nowhere, not even in yum.

First of all: Downgrades (aka going back to an older version) are not
supported in Debian. Full stop. It kinda works most of the time and the
lower in the stack the package is, the more likely it is actually that
it will work. yum is optimistic in this regard, apt isn't.


Graphical applications are far removed from "low in the stack" through.
Most, if not all will create & edit files in your home directory which
might be completely incompatible with previous versions. darktable
reminds me of this every other big version bump actually on the first
start of the new version as it will proceed to change the database then.
Many others also warn while most don't and just explode if you would
ever try (some games don't even have forward compat for their savegames,
I highly doubt they have backward compat…).

So a simple rollback of that one package wont work. What exactly do you
expect to happen if ~400 packages are involved?


We might get something like that some day. We introduced the history.log
sort of with this in mind, but haven't added much tooling to work with
it yet. But it will never work like you imagine here, as it simply
can't. It might work, if you are lucky, but if not, you have likely two
problems instead of one.


Best regards

David Kalnischkies

This relates to a prior thread that may be of interest from last month where
Julian Klode, one of the core APT devs from what I gather, mentions that
some level of rollback functionality is on the agenda. [1]



In case you are also a paying Canonical customer, I'd encourage you to
consider filing an RFE as I did so that the priority might be elevated
within Canonical possibly freeing up engineering sponsorship time.



I'm only recently back to Debian & Ubuntu from a quite long stint (10 years)
of doing RHEL-based Linux ops full time, and greatly miss the easy rollback
functionality within the YUM/DNF toolset.  I understand from experience that
it's absolutely not foolproof, and that the larger and more interconnected
the packages are that you want to roll back, the higher risk of adverse
effects, but despite all of that, having the capability to do such rollbacks
of smaller transactions in a rapid way really did allow us to drink from the
proverbial update firehose in weekly increments, with a reasonable degree of
confidence that any particular transaction that proved to be problematic had
a simple rollback solution.



My experience from a decade of leaning on this capability on a fleet of
about 450 hosts showed that in real world conditions so long as the
particular weekly update wasn't a major package drop (eg RHEL 7.4 --> RHEL
7.5), the success rate was so high that we took it for granted that it'd
basically always work so long as we weren't talking about something that
needed to be carefully ushered through an update "process" such as various
app+db stacks, which should all be marked in APT for holding anyhow.



Where this was critically useful to us on numerous occasions were in the
case of SSSD.  Updates to SSSD would generally arrive as an atomic bundle of
6-15 packages, and due to all of the varied environments out there for
Active Directory, would frequently arrive with subtle bugs or regressions
that would force a rollback across 50 or more systems within days to perhaps
2 weeks after the update had arrived.



Rolling this update back across a large number of systems by transaction ID
was relatively painless.



[1]: https://lists.debian.org/deity/2021/07/msg00031.html