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.
You're viewing a single thread.
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.
Storage wasn't my biggest issue (besides, I have 1tb internal ssd). It was that flatpaks couldnt communicate well with the rest of the environment. So I resorted to using flatpaks mainly for closed source apps that I wanted to isolate.
BUT, as I was making a script (https://github.com/BlastboomStrice/3rdPartyAutoUpdater) to automate github/gitlab/etc. updates (because the debian repo doesnt have them or they are outdated), I realized that I was essentially making a small scale version of nixos package manager.😆
So, now I'm very tempted to use the nix package manager and maybe do a full switch to NixOS (I'm not very advanced though, I havent even tried Arch, so ughh).
My mood concearning what distro to use on my laptop is rather volatile😅
You could always go for a Debian stable host as long as it supports your hardware and then use kvm/qemu to run virtual distros and see which one fits you the best.
I still havent transitioned to debian (still have win10 as main), I'm just booting to them from an external drive, so I can simply wipe the root partition any time I want to try a distro :)
Once I settle with a distro and manage to set it up the way I want, I will probably fully switch to linux (and maybe keep an image of my win10 os to run in a vm)
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.