I'm always afraid af to run ´apt autoremove´. Ever since it deleted smth called 'gir' like 7 years ago and broke my whole setup, I steer away from autoremove. Haven't run it for ~5years or so

just do regular full backups and break at will. And by that I mean learning by braking methodology

@We3D how many of us do whole system backups for an everyday laptop/pc, really? :)

@netikras If you use BTRFS you could use snapshots

@netikras idk really, not one of them :D

Just use something like Timeshift, and you'll never fear bricking your system again because you can easily roll back.

@Fast-Nop I've started once configuring it but there was a step ( don't remember the details ) that I thought is too troublesome to do it. But it seems like a good solution if you have many troubles keeping the OS fairly stable

@We3D I had no trouble at all, just kept the defaults. You have to make a choice for rsync or BTRFS, but if you're running the tried and tested ext4, it's only rsync anyway.

It's not that I have to use Timeshift for system stability, it's just for peace of mind so that I can blindly accept updates.

@theKarlisK RPM vs apt has nothing to do with bugs in the dependency lists.

Set up btrfs with auto snapshots in pacman years ago. Before that manual and before that I was a sysadmin livecd/stick to the rescue.
I use Arch btw.

Wonder how you got your apt db in a state of that it messed up an autoremove.

@Fast-Nop btrfs is also tried and tested. I've had minor issues with both. Ext4 in a server when it was new, and super performant but dangerous. BTRFS a bit more recently. It had one specific kernel version i.c.m. SSD stuff that could and did mess some stuff up.
No system is bulletproof but I dare say they are both highly reliable. Snapshots do not allow for recovery in all scenarios though.

As a debian adept I read the comments here in disbelief. Aside from the discussion of which package manager is the best (they all are and are not at the same time, they all have pros and cons) . With pure debian this has never in my entire life gone wrong. The preconditions being that you run on stable releases (Sid is Sid after all) , keep your repo's clean and don't Frankenstein it with unverified/untrusted repos that package their own library dependencies which could overwrite them.

Most of these issues can also be caught before upgrades by 'dry running' your upgrades and check diffs. The --simulate flag is key here.

Last but not least: read release notes!

That is a very! very! good idea - coming from someone who just got dicked over by some similar fuckery.

@JS-Guy what is?

@netikras Not doing autoremove. I lost an nvidia driver that way.

@JS-Guy right! I lost nvidia drivers to autoremove too!! Yyyyears ago

Look at the list it gives you before you type Y, and you won't have this problem. If you're really cautious/suspicious of orphaned dependencies like I am, check why each one was originally installed before confirming the autoremove.

I can understand not realizing that a package named "gir" will break things if you remove it, but if you managed to autoremove your Nvidia drivers, that's on you lol.

@EmberQuill when the list is ~800 items... Looking at the list approaches the "meeh.. Maybe later.." line

@netikras If the list is 800 items, just give up and reinstall Ubuntu lmao