3 ms·

Maybe the situation is different on the server side or I've just been extremely unlucky, but I keep getting my packages broken. Just a few days ago I was instal

by franga2000 6y ago

Maybe the situation is different on the server side or I've just been extremely unlucky, but I keep getting my packages broken. Just a few days ago I was installing Wireguard on a Stretch system (added unstable repo, lowest priority, pinned packages) and APT got tangled up to the point where I couldn't install almost anything because one package was too new, but trying to remove it went down the dependency tree all the way to `util-linux` and I had to do surgery with `dpkg -r --force-depends` to fix it.

bayindirh 6y ago
On the server side, I only use stable (due to security updates and other critical stuff). Using testing in three desktop systems (two at office, one at home) currently, all workstations which see regular, heavy usage. To add unstable packages to a stable system with repo pinning and using apt directly is not the best practice though. If I'm going to add stuff from unstable, I use aptitude. Its dependency resolution and solution suggestions are better and more manageable than ordinary apt. It allows you what's going to happen before actually pulling the trigger. The only package I get from unstable is firefox. I add the repo, update the package and remove the repo afterwards because unstable and experimental are highly chaotic realms and not suitable to use continuously due to high rate of uncontrolled change. Also unstable and experimental are not guaranteed to not to break. Testing and stable are implicitly (testing) and explicitly (stable) is guaranteed to work. With this recipe, I only had to re-install a Debian system once; to migrate it from 32 to 64 bits since a very big disk cache with very small files was triggering a bug causing disks to trash and system slow down to a crawl. There were no procedures to migrate a 32 bit system to a 64 one in a reliable manner so, I just reinstalled it.

bayindirh 6y ago

On the server side, I only use stable (due to security updates and other critical stuff). Using testing in three desktop systems (two at office, one at home) currently, all workstations which see regular, heavy usage. To add unstable packages to a stable system with repo pinning and using apt directly is not the best practice though. If I'm going to add stuff from unstable, I use aptitude. Its dependency resolution and solution suggestions are better and more manageable than ordinary apt. It allows you what's going to happen before actually pulling the trigger. The only package I get from unstable is firefox. I add the repo, update the package and remove the repo afterwards because unstable and experimental are highly chaotic realms and not suitable to use continuously due to high rate of uncontrolled change. Also unstable and experimental are not guaranteed to not to break. Testing and stable are implicitly (testing) and explicitly (stable) is guaranteed to work. With this recipe, I only had to re-install a Debian system once; to migrate it from 32 to 64 bits since a very big disk cache with very small files was triggering a bug causing disks to trash and system slow down to a crawl. There were no procedures to migrate a 32 bit system to a 64 one in a reliable manner so, I just reinstalled it.