Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #183257 > unrolled thread

Relative stability of Testing vs Unstable

Back to article view | Back to linux.debian.user

Contents

  Relative stability of Testing vs Unstable Jason Cohen <jwittlincohen@gmail.com> - 2017-07-06 02:20 +0200
    Re: Relative stability of Testing vs Unstable Bob Weber <bobrweber@gmail.com> - 2017-07-06 03:40 +0200
    Re: Relative stability of Testing vs Unstable Jimmy Johnson <field.engineer@gmail.com> - 2017-07-06 04:10 +0200
      Re: Relative stability of Testing vs Unstable John Hasler <jhasler@newsguy.com> - 2017-07-06 04:30 +0200
        Re: Relative stability of Testing vs Unstable Jimmy Johnson <field.engineer@gmail.com> - 2017-07-06 05:40 +0200
        Re: Relative stability of Testing vs Unstable <tomas@tuxteam.de> - 2017-07-06 10:10 +0200
          Re: Relative stability of Testing vs Unstable Fungi4All <fungilife@protonmail.com> - 2017-07-06 10:40 +0200
          Re: Relative stability of Testing vs Unstable John Hasler <jhasler@newsguy.com> - 2017-07-06 14:00 +0200
            Re: Relative stability of Testing vs Unstable <tomas@tuxteam.de> - 2017-07-06 14:30 +0200
    Re: Relative stability of Testing vs Unstable Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-07-06 06:00 +0200
      Re: Relative stability of Testing vs Unstable John Hasler <jhasler@newsguy.com> - 2017-07-06 13:50 +0200
    Re: Relative stability of Testing vs Unstable songbird <songbird@anthive.com> - 2017-07-06 13:50 +0200
      Re: Relative stability of Testing vs Unstable John Hasler <jhasler@newsguy.com> - 2017-07-06 14:10 +0200
        Re: Relative stability of Testing vs Unstable songbird <songbird@anthive.com> - 2017-07-06 23:00 +0200
          Re: Relative stability of Testing vs Unstable Fungi4All <fungilife@protonmail.com> - 2017-07-07 19:20 +0200

#183257 — Relative stability of Testing vs Unstable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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]. 

One user described the releases this way: "Stable is never broken;
Unstable is immediately fixed; Testing is neither" [3]. A Debian
developer seemingly agreed, responding "That's because some things
might break in testing during migration.  E.g., when we upload a new
major release of something like MATE and half of the packages take a
bit longer to migrate to testing, you end up with half of the packages
of MATE in testing on the old major version and the other half being on
the new major version. This will definitely break" [4].  Chris Lamb
also seemed to agree, asking the user why he had not considered
Unstable over Testing [4].

In light of the above, it's not clear to me whether I should use
Testing or Unstable. Presumably there are situations where one is
better than the other.  From what I read, very serious bugs are likely
to be caught before making it to Testing, while Unstable benefits from
getting security updates (in the form of new upstream releases) sooner,
and is more likely to be consistent during transitions.  It would be
useful to hear more about the pros and cons of each release.

In either case, I will be using ZFS for the root pool (I've been using
ZFS on Linux for years and I love its resiliency to hardware failure
and features) and take daily backups with bacula.  As such, I can
snapshot before an upgrade and rollback to the snapshot from an
initramfs shell if an update somehow makes the system unbootable or
otherwise causes serious breakage.  As long as I take basic precautions
such as reviewing the output of apt-listbugs and making sure that an
'apt-get dist-upgrade' doesn't want to remove half my system, am I
likely to experience frequent breakage with either release[5]?  What
other steps can I take to avoid breakage?

Thanks in advance for the information,

Jason

[1] https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-test
ing and https://www.debian.org/releases/
[2]https://www.reddit.com/r/debian/comments/5h5pvb/is_debian_testing_wo
rth_over_arch_linux/day5l8m/
[3]https://www.reddit.com/r/debian/comments/5h5pvb/is_debian_testing_wo
rth_over_arch_linux/daxr98u/
[4] https://www.reddit.com/r/debian/comments/5h5pvb/is_debian_testing_w
orth_over_arch_linux/daxpyj0/
[5]https://wiki.debian.org/DebianUnstable
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEq7ncLkwZsndhZmLWsskfuEl+i10FAlldgYcACgkQsskfuEl+
i12PBQ/7BDaI2dtUjFDc4Ifx5FDdwT5YaFshg7zinq7pbsvL1VF5y5IaTBB46pHX
rVTUE79F8R6ONyTF0Sw97mnT8rxY34XH4oqOVSqe23ZTs++wnAc9g/ZtjyNsg6eM
kKyqim9+pi7MLrihkO4/999TXR3dSrv/PzKW8p5uOGS4yqkBPMIildG/hrZ4BilD
mJdhU6qLPrsTg+hmNBDikZOHfGA+ZmtxYHm0A5CZze7qnvFwLmNq39+OysBr2zRw
TmfP+KbWMqSlpp859sk+hugRj7TDnADPb2uAZvhMXK7Xo676VcefvdX+fkLsCzZu
jiOabsTFeGHr2e1ACLrxMJsBv55R1ySBYwuflaaTlpAWD2Xt9K4G0rSOKsiPTVS7
pR2k3bOpzgs3jSl+plWIAEFsSp/OjMg11Ow7DGdKWPo2RW2Kx5kcTMidSfa0ZkUI
ZE2d3T5cCnPpfZ9MtyG2c9lQSX9RMrky3UNIWTqOUEzpwNhKP8gN5fsgNQSIDOYV
WGc/fQzm2R46pvfVEKxMCcFfF4nz3CYUuWmQGPKa8GqtTI13/eW61gfWtuq6mRo8
wWRPiKuu/M/Op1EMcj2974PqPNH0U4kgWpvzYYkZkg2uS3Z8cP3DnQKd86XS/qhA
cnczuP7g+VqhtK/iz+/WPDKfVosFRoctMvWY+h4/3eSArrGQY58=
=IEce
-----END PGP SIGNATURE-----

[toc] | [next] | [standalone]

#183259

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

[toc] | [prev] | [next] | [standalone]

#183261

On 07/05/2017 05:17 PM, Jason Cohen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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].
>
> One user described the releases this way: "Stable is never broken;
> Unstable is immediately fixed; Testing is neither" [3]. A Debian
> developer seemingly agreed, responding "That's because some things
> might break in testing during migration.  E.g., when we upload a new
> major release of something like MATE and half of the packages take a
> bit longer to migrate to testing, you end up with half of the packages
> of MATE in testing on the old major version and the other half being on
> the new major version. This will definitely break" [4].  Chris Lamb
> also seemed to agree, asking the user why he had not considered
> Unstable over Testing [4].
>
> In light of the above, it's not clear to me whether I should use
> Testing or Unstable. Presumably there are situations where one is
> better than the other.  From what I read, very serious bugs are likely
> to be caught before making it to Testing, while Unstable benefits from
> getting security updates (in the form of new upstream releases) sooner,
> and is more likely to be consistent during transitions.  It would be
> useful to hear more about the pros and cons of each release.
>
> In either case, I will be using ZFS for the root pool (I've been using
> ZFS on Linux for years and I love its resiliency to hardware failure
> and features) and take daily backups with bacula.  As such, I can
> snapshot before an upgrade and rollback to the snapshot from an
> initramfs shell if an update somehow makes the system unbootable or
> otherwise causes serious breakage.  As long as I take basic precautions
> such as reviewing the output of apt-listbugs and making sure that an
> 'apt-get dist-upgrade' doesn't want to remove half my system, am I
> likely to experience frequent breakage with either release[5]?  What
> other steps can I take to avoid breakage?
>
> Thanks in advance for the information,
>
> Jason


I'll bite!

As a user and a Linux Tester for more than 20yrs, I can say all upstream 
is going to have problems, including your best rolling release. Someone 
has to test and someone has to fix the problem or the package gets 
dropped or you just have a crappy system.  Do you enjoy fixing problems, 
finding a workaround to see a release threw to the end and then start 
testing(basically that's what you are doing) the next release.

Or maybe just run testing, same thing, in both the problems are 
seasonal, new kernel, new driver, new infrastructure, etc.

For stability, the older your Debian system is the better, can it handle 
your hardware and can you install the package you need.

If you like working around problems and using the latest apps 
Sid/Testing is a blast!

Cheers,
-- 
Jimmy Johnson

Debian Buster - KDE Plasma 5.8.7 - Intel G3220 - EXT4 at sda14
Registered Linux User #380263

[toc] | [prev] | [next] | [standalone]

#183262

Jimmy Johnson writes:
> From what I read, very serious bugs are likely to be caught before
> making it to Testing, while Unstable benefits from getting security
> updates (in the form of new upstream releases) sooner, and is more
> likely to be consistent during transitions.

Unstable is not required to be consistent at all.

That said, I've always used it on my desktop and have not had a problem
for at least ten years.  However, I use FVWM rather than a desktop
environment.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#183264

On 07/05/2017 07:24 PM, John Hasler wrote:
> Jimmy Johnson writes:
>>  From what I read, very serious bugs are likely to be caught before
>> making it to Testing, while Unstable benefits from getting security
>> updates (in the form of new upstream releases) sooner, and is more
>> likely to be consistent during transitions.

I've read that before someplace, but I did not write it.  But I tend to 
agree, also packages are suppose to be working in theory before going to 
Sid, just not yet tested, sometimes a package will be downgraded and 
that obsolete package may not be so obsolete after all, if you're not 
paying attention you can screw a system up and the same thing can happen 
in testing too.

> Unstable is not required to be consistent at all.
> 
> That said, I've always used it on my desktop and have not had a problem
> for at least ten years.  However, I use FVWM rather than a desktop
> environment.

Me too. :)

This Sid system is more than 15yrs old, has seen many releases, three 
different hard drives and at lest 5 different desktop computers, intel, 
ati and nvidia too. However, I use KDE, always have, I've used other 
environments and I could get used to the idea of right clicking on my 
desktop and finding what I want.

Cheers,
-- 
Jimmy Johnson

Debian Sid/Testing - KDE Plasma 5.8.7 - Linux 4.9 - EXT4 at sda15
Registered Linux User #380263

[toc] | [prev] | [next] | [standalone]

#183273

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jul 05, 2017 at 09:24:08PM -0500, John Hasler wrote:
> Jimmy Johnson writes:
> > From what I read, very serious bugs are likely to be caught before
> > making it to Testing, while Unstable benefits from getting security
> > updates (in the form of new upstream releases) sooner, and is more
> > likely to be consistent during transitions.
> 
> Unstable is not required to be consistent at all.
> 
> That said, I've always used it on my desktop and have not had a problem
> for at least ten years.  However, I use FVWM rather than a desktop
> environment.

I think that's an important point: it's not only "what do you use it
for" or "how much you enjoy tinkering" but also "what is on your system".

Big, heavily interdependent systems consisting of lots of packages
(big language environments à la Perl, Python, Java -- but most prominently
big desktop environments) are especially vulnerable to version churn,
which typically happens in testing once in its life cycle.

People with a simple setup (e.g. just a window manager) perhaps won't
even notice anything happened.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlld7fUACgkQBcgs9XrR2kbJnwCfTj6q41PaTpNujGElKv7PQA+y
kBIAnjvSouQZysPYLU3SxOov+1RuX3ls
=lKZ3
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#183275

[Multipart message — attachments visible in raw view] — view raw

I can not help much in developing or bug analysis, so my contribution has been to test
what is handed out to me for testing. I have yet not been able to contribute much as
nothing seems to break in testing or sid (amd64 openbox/lxde) ever. Sometimes I
wonder when I read the list or archives things being problematic for stable that I
have never encountered. Maybe lucky, maybe not trying hard enough.
What I have learned testing different distributions is that "stable" and secure are not
nearly associated as many people think. My latest favority other distribution has been
Manjaro. I currently run linux 4.9/4.11/4.12 in testing there, no problems. Some packages
in Manjaro stable are 2-3 years advanced in development than what is maintained in
Debian. Very few functionality problems (they can't seem to work along with the grub team).
But, is everything going through the same kind of scrutiny with debian or are people
exposed to 2-3 years of risk before debian discovers the problem before it introduces a
package version in sid? I can not yet tell.
So when I am in worry free mode of whatever happens happens, I use Manjaro.
For everything else I use testing and sid.
9/10 of debian based distros has been a waste of time and 0 learning value. My
ordered favorites within the 1/10 has been kali, siduction, tails (for the shake of
keeping an eye of what is changing in that field and getting security ideas) .
But they are almost clean debian with some custom extra packages.
Switching from Debian to Manjaro is like parking the dodge (slant 6) van for
daily use and picking up the sportbike for a careless rural ride. You just can't
go to work with a full leather uniform or park it at the metro station.
This is my experience with it all.
PS There has been a glimpse of an issue of "security for nothing" in Debian
as I have been able to place files or edit files at my Debian /home from
Manjaro but not the other way around. So I wonder, if manjaro root can
read and write in my debian-user's /home where is the security in being
unable as debian root to even take a peak at the user's directory?
Don't trust your arch/manjaro sys-admin but feel comfortable with Debian
sys-admin, unless he is booting a different system? For a single
user system Debian makes your life harder, hopefully not for nothing.

[toc] | [prev] | [next] | [standalone]

#183292

tomas writes:
> Big, heavily interdependent systems consisting of lots of packages
> (big language environments à la Perl, Python, Java -- but most
> prominently big desktop environments) are especially vulnerable to
> version churn, which typically happens in testing once in its life
> cycle.

I have full Perl and Python environments and I sometimes run CFD, FEM
and CAD packages.  I think that the key is that I scan debian-dev for
warnings and don't try to "track" Unstable by upgrading daily.  It's
best not to upgrade during the first few weeks after a release.

> People with a simple setup (e.g. just a window manager) perhaps won't
> even notice anything happened.

I don't think "just a window manager" quite describes FVWM.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#183300

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jul 06, 2017 at 06:52:13AM -0500, John Hasler wrote:
> tomas writes:
> > Big, heavily interdependent systems [...]

> I have full Perl and Python environments and I sometimes run CFD, FEM
> and CAD packages.  I think that the key is that I scan debian-dev for
> warnings and don't try to "track" Unstable by upgrading daily.  It's
> best not to upgrade during the first few weeks after a release.

Yes, those two practices go a long way towards keeping you out of
trouble.

> I don't think "just a window manager" quite describes FVWM.

:-)

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlleLSUACgkQBcgs9XrR2kb/kQCfd7EJWLCfr+qFAt+onx0OIjLK
+YUAnR/QS64aAQQTB6j0MapnfInICfy/
=N1zi
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#183266

My experience, solely as a user, has been that sometimes the unstable
distribution breaks and you're hosed.  I can't remember when I was last
burned by running testing.

[toc] | [prev] | [next] | [standalone]

#183290

> My experience, solely as a user, has been that sometimes the unstable
> distribution breaks and you're hosed.  I can't remember when I was
> last burned by running testing.

I can't remember when I was last burned by Unstable.  It is necessary to
follow debian-dev to know when not to upgrade.  I also do not upgrade
very frequently
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#183291

Jason Cohen wrote:
...
> 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 keep two bootable partitions available and upgrade
them out of step so that i always have at least one
that works well enough i can get my required tasks done.

  i've been running testing with bits from unstable
and/or experimental for quite some time now.  i've 
had problems here or there with different pieces but
only rarely been bitten where i did not have things
running at all.  luckily all situations were fixable
without reinstallation.

  i'm very happy with how it has been going.  i think 
Debian rocks and i'm very appreciative of everyone who 
makes any sort of contribution to the on-going 
development and packaging.


  songbird

[toc] | [prev] | [next] | [standalone]

#183295

songbird writes:
> i've been running testing with bits from unstable and/or experimental
> for quite some time now.

Experimental is a completely different kettle of fish.  Unstable
contains packages that the developer hopes and expects will migrate to
Testing and end up in Stable without incident, and he's usually right.
Experimental, on the other hand, contains packages that the developer
wants people to experiment with.  It is not a mistake or policy
violation to upload a package known to contain a grave bug to
Experimental.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#183318

John Hasler wrote:
> songbird writes:
>> i've been running testing with bits from unstable and/or experimental
>> for quite some time now.
>
> Experimental is a completely different kettle of fish.

  of course.  :)  it is not like i'm using a lot of
things from there.  more like one or two items.


>  Unstable
> contains packages that the developer hopes and expects will migrate to
> Testing and end up in Stable without incident, and he's usually right.
> Experimental, on the other hand, contains packages that the developer
> wants people to experiment with.  It is not a mistake or policy
> violation to upload a package known to contain a grave bug to
> Experimental.

  i usually check if there is a newer version there
if i'm experiencing a bug in a version that is in
testing or unstable to see if the newer version solves
the bug.  most recently it was libreoffice, but the
newer version didn't make any difference so i purged
it and reinstalled the testing version again (and then
worked around the issue).


  songbird

[toc] | [prev] | [next] | [standalone]

#183345

[Multipart message — attachments visible in raw view] — view raw

> From: songbird@anthive.com
> To: debian-user@lists.debian.org
> John Hasler wrote:
>> songbird writes:
>>> i"ve been running testing with bits from unstable and/or experimental
>>> for quite some time now.
>>
>> Experimental is a completely different kettle of fish.
> of course. :) it is not like i"m using a lot of
> things from there. more like one or two items.
>> Unstable
>> contains packages that the developer hopes and expects will migrate to
>> Testing and end up in Stable without incident, and he"s usually right.
>> Experimental, on the other hand, contains packages that the developer
>> wants people to experiment with. It is not a mistake or policy
>> violation to upload a package known to contain a grave bug to
>> Experimental.
> i usually check if there is a newer version there
> if i"m experiencing a bug in a version that is in
> testing or unstable to see if the newer version solves
> the bug. most recently it was libreoffice, but the
> newer version didn"t make any difference so i purged
> it and reinstalled the testing version again (and then
> worked around the issue).

between sid and experimental it is only a pound sign move from one
source line to the next. An update will satisfy your curiosity without
an upgrade. Last I checked there were only 2-3 kernels that were
under experimentation, nothing else different from my sid installation.
Do I care to mess around with linux-rc ? Not really, so I just went
back. Possibly after stretch stability there may be a ton of stuff.
By the way, 4.12 was announced as stable and there is no 4.13
yet. https://www.kernel.org/

> songbird

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web