Using Debian Stable as complementary to Testing
Using Debian Stable as complementary to Testing
Hello everyone! It's been about a month that I'm experimenting Debian on an external disk. For the most time, I've been using Testing. The issue is, that some packages are missing from Testing, while they exist on Stable (or on Unstable). The biggest problem with that is that some packages require dependencies that don't exist on the Testing repo and as such I can't install those apps.
So, I thought about adding the Stable repo, at a lower priority. If something doesn't exist on Testing, it will grab it from Stable.
How bad is that approach? I'm not doing the reverse (using stable and grabbing apps from testing), which might be way worse. Does anyone else do that? I couldn't find anything related online.
PS. I'm a bit tempted to switch to Unstable all together, but I don't know if I'll be careful enough to use it in the long run.
PPS. I might build a home nas at some point (with Debian Stable) and keep regular backups of my laptop so that I'll be kinda safe if I ever switch to Unstable.
Here's a good read regarding the different versions:
https://www.debian.org/doc/manuals/debian-faq/choosing.en.html3.1.5. Could you tell me whether to install stable, testing or unstable?
No. This is a rather subjective issue. There is no perfect answer as it depends on your software needs, your willingness to deal with possible breakage, and your experience in system administration. Here are some tips:Stable is rock solid. It does not break and has full security support. But it not might have support for the latest hardware.
Testing has more up-to-date software than Stable, and it breaks less often than Unstable. But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times. It also does not have permanent security support.
Unstable has the latest software and changes a lot. Consequently, it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.
Personally I mostly run Debian Stable and on the one machine where I don't I run a completely different distro altogheter (Fedora). If I didn't run Fedora I would rather use Sid (unstable) than Testing.
I see I see, thank you for you quick reply. This tempts me even more to use sid, hmm.
This is a different question from the original post, but do you happen to know what to do when listbugs warns me that a package has bugs? I suppose almost all packages have some bugs to some degree. Should I just avoid them on Sid? Or should I check how bad the bug is (if it belongs to a serious category) and decide whether to update it?
I say the solution is one step earlier. Backups and snapshots.
Use BTRFS or ZFS filesystem on your install and use snapshots to be able to rollback if things go bad.
Here's an example on how to set up BTRFS with automatic snapshots:
https://github.com/david-cortes/snapper-in-debian-guideFor backups Borg is popular:
https://github.com/borgbackup/borg
I use Testing on my desktop. When that happens, I just switch to the Flatpak.
Honestly, I’ve grown tired of Testing. I’ve started to become a fan of stable with a few Flatpaks.
Yeah, I see what you mean.
I initially thought about using flatpaks for almost every non-core app, but then I found out that 1) it's hard for flatpak apps to communicate with the rest of the system and 2) for a 10Mb app, 1+Gb might be downloaded. So, I'm trying to avoid these too🥲
Also, some packages dont even have flatpaks, so I grab packages from github (and installing .deb packages on testing may lead to failed installs due to missing dependencies....)🥲
I came into Debian with that philosophy as well, but I eventually gave up on all native packages as I got tired of having to deal with the rotation of some testing packages.
Honestly, 1 GB is an extreme it could get to, but most don’t because the majority of that initial 1 GB overhead is shared with other applications. Part of this is design issues in glibc preventing reverse compatibility with older glibc applications, and so applications need to have the right version of glibc with them to work. This adds some overhead, but is mitigated because many Flatpaks use the same glibc version.
Also, to be honest, storage is cheap these days, and really, I think the ease of Flatpak is worth what becomes a pretty minor storage sacrifice.
Flatpaks share dependencies so after your first half dozen or so then the overhead for the rest isn't very large. They simply reuse that 1+Gb you installed for the first batch.
With that said, I also prefer native applications from a .deb or .rpm when possible and for no proper reason other than being used to doing it that way.