On 7/5/17 8:17 PM, Jason Cohen wrote: > I've been using Debian for a number of years, but my experience has > typically been with servers where I have used the Stable branch for its > reliability and security support. However, I recently began using > Debian Stretch for my desktop and foresee a need for more frequent > software updates than the approximate 2 year cadence of the Stable > release. While the backports repository is great, it only covers a > small subset of packages. > > My question is how Debian Testing and Unstable compare in terms of > stability. The Debian documentation suggests that Testing is more > stable than Unstable because packages are delayed by 2-10 days and can > only be promoted if no RC bugs are opened in that period [1]. Yet, > other sources indicate that Testing can stay broken for weeks due to > large transitions or the freeze before a new stable release [2]. > I have been using testing/kde for several years now and have been bit by some of these transitions. I use ext4 so my snapshot is made by rsnapshot (rsync wrapper). I have had to restore from this snapshot several time when my system won't go into graphics node. Unfortunately rsync has failed when a package has a file with the same date and time but is actually different as seen by its md5sum. There is an explanation for this behavior but I never understood it. To me a file should never have the same date and time but actually be different. rsync's checksum option is very slow!. Apparently there is a fix coming to the way packages are generated which will fix this! I use debsums -ca to check all the package files. I also have a apt-cache-ng server running so that I can always go back to a previous package if needed or pick up a package that has failed debsums. I also run several VMs with various testing and unstable systems so I can see for myself what works. I use testing and unstable source list files and pinning to determine what each system uses. For testing:
Package: * Pin: release a=testing Pin-Priority: 900 Package: * Pin: release a=unstable Pin-Priority: 800 Just reverse the pin priory for unstable. This way if I see a package in unstable that I want to try in a testing system I can specify the version number in the install command like this. apt install package=version You can also use apt-mark to set a hold on a package if you see problems others are having with a package in the various debian lists. I did this for some xorg packages a while back to wait for a fix to propagate out. I have a grub boot option to boot to a iso copy of SystemRescueCd if I need to restore files or tweak the system. On top of all this I have a backuppc server backing up all my systems so if I forget a snapshot before a upgrade I still have a backup. I use software raid1 so I can survive a single disk failure. It also allows me to add a disk to the array and pull it after it is synced up and put in a off site storage to have a backup from a fire or water damage event. In my experience testing gets very "stable" running up to a new release. Just before the last release I spent a day updating all my systems/laptops so that I would be about at that stable point. I have not updated my main system since and now apt wants to update 744 (after about 20 days) packages! I haven't seen any major problems in my VMs that I update every day so I suppose I will update it in a few days. ...Bob