This is impossible. Debian packages are stateful: They have maintainer scripts that can do stuff, they are inherently non-transactional by design.
Even if you can rollback updates, a lot of the time that's no help - your user data format was upgraded, rendering your data useless (especially for web browsers, which you can't really downgrade).
That said, it's trivial to use file system snapshots. Ubuntu has apt-btrfs-snapshot to do this automatically, but it was never provided in Debian AFAICT.
But even with snapshots, you also need to snapshot user state, not just the installation, otherwise you end up with upgraded incompatible data again.
I've done this before, usually you just contact the upstream maintainer, get access to the project either from them or via the abandoned projects takeover process of the project hosting provider, make a new release and file a bug with the Debian maintainer documenting the new release and new maintainer.
When I upgrade, I pay close attention to the package change lists. If packages are set to be removed, especially a lot of important looking packages, I cancel the upgrade and investigate. Usually this means that something has gone wonky with dependencies, or not all of the packages that need to be upgraded in lock-step are available yet. Usually this resolves itself after a few days, but sometimes you can coax a partial upgrade if you find the culprit package and hold it.
Speaking of holding, apt-mark hold/unhold (or equivalent - I think there might be a better way to do this now) is your friend. I usually end up holding packages like the ones mentioned above that erroneously want to remove half the system, as well as any packages that apt-listbugs complains about, unless I've reviewed the bug report and am okay with it. I'll periodically unhold everything (apt-mark showhold | xargs sudo apt-mark unhold), then retry an upgrade to see which bugs or dependencies have been fixed, and then hold any remaining offenders again. Usually this will end up "releasing" package upgrades in chunks depending on the dependency graph.
Apt should probably be louder when big parts of the system get marked for removal. I think this the primary way testing/unstable systems end up breaking, and it's completely avoidable.
At least I found a kind of starting point (although I am not sure what the criteria for a debian stable package are to be put in that list): https://packages.debian.org/stable/
For those running testing (or sid/experimental) I highly recommend apt-listbugs -- it will list (critical) bugs related to packages you're about to upgrade/install -- and allow you to back out. Often you can just hold off a few days, and some hardworking Debian volunteer will have made the problem go away -- before you need to experience it.
For interactivity that should in principle be a solved problem with debconf, if it's not, we would like to hear what's lacking. If there is a problem with a particular package then a bug report would be appreciated.
Debian keeps track of all remaining privacy issues in all packages (i.e. such issues which have not yet been corrected or patched by the Debian package maintainer):
The situation has improved, actually - you'd still have to do custom scripting to check the output checksums AFAIK but ex. https://tests.reproducible-builds.org/debian/reproducible.ht... tracks Debian's attempts to make it possible to reproduce packages perfectly. It's just that nixos made it pervasive and normal through the whole system.
When I fix something, I immediately send it upstream, did you do that? I just did it now after I fixed a bug, so that neither me nor anyone else has the problem in the future. Debian has a program called „reportbug“ which you invoke with the package or file name related to the bug, even if you do not have a solution.
I think a distribution like Debian should appeal to you for its focus on quality. New packages in Debian move first to the Unstable distribution and then after some time to the Testing distribution. Testing is “freezed” before a Stable release to weed out remaining bugs. [1]
Debian also has a tool called “apt-listbug” that warns you before installing a new version of a package that has a known bug and gives you an option to not update that package automatically for as long as that bug exists.
What Ubuntu does is just putting its own stuff on top of Debian Unstable (or Testing, when it does a Long Term Support release). They have next to no quality control. When I drew glyphs for Unifont, this meant that for half a year, Ubuntu had a half-finished Unifont it imported from Debian Testing at the wrong time. I got complaints as I told people to install Unifont to play my Unicode proof-of-concept roguelike [2].
The guy from the article I wrote eventually did use Debian. I think he fiddled around with Emacs for over a month until he arrived at his “perfect” setup (which is different for everyone, by the way).
https://manpages.debian.org/testing/devscripts/debbisect.1.e... https://wiki.debian.org/BisectDebian
reply