Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

With snapshot.debian.org you can roll back to any version of any package that has been saved. Using that you can even bisect where issues started.

https://manpages.debian.org/testing/devscripts/debbisect.1.e... https://wiki.debian.org/BisectDebian



sort by: page size:

It should be easy to go back to https://snapshot.debian.org/ and one more repository and verify old untainted releases between the two archives.

Come back to Debian (testing, if you want new package versions).

You may want to submit a bug report: https://www.debian.org/Bugs/Reporting

This will more likely result in the package being removed rather than fixed, but at least someone else won't get false hope.


The Debian snapshot server only has copies of every Debian source/binary package going back to 2005 :(

https://snapshot.debian.org/

There are copies of the older releases on the archive though:

https://archive.debian.org/


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.


Another tool for that is checkbashisms from the Debian devscripts package:

https://manpages.debian.org/checkbashisms


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.

Here are the official suggestions:

https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...

apt-listbugs is really the main one for me.

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/

The backports repo solves most of it, with an occasional supplement from testing.

    # /etc/apt/preferences
    Package: *
    Pin: release o=Debian Backports,a=bullseye-backports
    Pin-Priority: 500
    
    Package: *
    Pin: release o=Debian,a=stable
    Pin-Priority: 100
    
    Package: *
    Pin: release o=Debian,a=testing
    Pin-Priority: 98
    
    Package: *
    Pin: release o=Debian,a=unstable
    Pin-Priority: 50
Then:

    $ apt-cache policy ripgrep fzf jq
    ripgrep:
      Installed: (none)
      Candidate: 12.1.1-1+b1
      Version table:
         13.0.0-2 98
             50 http://ftp.us.debian.org/debian unstable/main amd64 Packages
             98 http://ftp.us.debian.org/debian testing/main amd64 Packages
         12.1.1-1+b1 100
            100 http://deb.debian.org/debian bullseye/main amd64 Packages
    fzf:
      Installed: (none)
      Candidate: 0.24.3-1+b6
      Version table:
         0.29.0-1 98
             50 http://ftp.us.debian.org/debian unstable/main amd64 Packages
             98 http://ftp.us.debian.org/debian testing/main amd64 Packages
         0.24.3-1+b6 100
            100 http://deb.debian.org/debian bullseye/main amd64 Packages
    jq:
      Installed: 1.6-2.1
      Candidate: 1.6-2.1
      Version table:
     *** 1.6-2.1 100
            100 http://deb.debian.org/debian bullseye/main amd64 Packages
             50 http://ftp.us.debian.org/debian unstable/main amd64 Packages
             98 http://ftp.us.debian.org/debian testing/main amd64 Packages
            100 /var/lib/dpkg/status

PS. Don't curl into /usr/bin, the distro owns that. Downloads go to $HOME/bin or /usr/local/bin.

Also see "needrestart", which automatically offers to do the above when upgraded packages have been installed: https://packages.debian.org/jessie/needrestart

@giancarlostoro

This is the solution. Use the following web page to compare packages versions from Debian Testing and Fedora 40: https://distrowatch.com/dwres.php?firstlist=debian&secondlis...


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.

I assume you mean maintainer scripts here. If so we are already going in that direction: https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging

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):

https://wiki.debian.org/PrivacyIssues


Packages in unstable can enter testing in 2-10 days, not years :) https://wiki.debian.org/DebianTesting

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.

Quite often there are many vulnerabilities with no ‘fixed-in’ version (as it’s not yet fixed) and this can be for some time.

https://security-tracker.debian.org/tracker/status/release/s... is one place to look through in the past I think there was a better link I used to use to find all vulnerable packages which were awaiting a fix - but I can’t seem to find it now.


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).

[1] https://en.wikipedia.org/wiki/Debian

[2] http://news.dieweltistgarnichtso.net/notes/zoo-tycoon-roguel...

next

Legal | privacy