Re: Relative stability of Testing vs Unstable
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
Reply to: