on Sun, Apr 18, 2004 at 10:36:35AM -0800, Ken Irving (fnkci@uaf.edu) wrote:
> On Sat, Apr 17, 2004 at 07:39:19PM -0700, Karsten M. Self wrote:
> > on Fri, Apr 16, 2004 at 09:26:53AM -0700, Robin Lynn Frank (rlfrank@paradigm-omega.com) wrote:
> > Basic benefits:
> >
> > ...
> >
> > - Choice of stability / currency tradeoff points with different Debian
> > releases: stable (old but rock solid), testing (equivalent to most
> > other distro's current release), ...
>
> This statement seems at odds with recent list discussions of the nature
> of testing, which point out that testing may break for various reasons
> and is slow to get security updates.
Testing breaks relatively infrequently, but often stays broken for a
longer period of time, than unstable. The security updates issue is one
that needs to be considered.
As a result, I run testing/unstable, with a default pin of testing, but
selected packages installed from unstable, on my own desktops *and*
servers. I've also got over five years' experience with Debian and
generally understand the packaging system and project pretty well.
I'd recommend running Debian for 3-6 months before hopping onto the
unstable track for any critical systems (for varying levels of
critical).
The situation is largely an outfall of Debian testing's inclusion
policy: packages enter testing:
- Ten days after release to unstable.
- If no critical bugs are filed against the package.
- If no dependencies against other packages are unmet.
- Unless explicitly overridden by the release manager(s).
Generally, many bugs _are_ caught in the first ten days of release.
Which means that for unstable, you'll have relatively frequent, but
(hopefully) short-lived breakage. This can be deceptive particularly in
relatively stable periods of release for people who try unstable,
sometimes lasting for 6-12 months. After which all hell breaks loose,
and we on the #debian IRC channel (irc.debian.org) see lots of "how do I
downgrade from unstable to stable" questions (answer: you don't).
When bugs *do* hit testing, however, they tend to stay there for a
while. Because the fixes themselves take at least ten days to propogate
through.
*This* is why seasoned vets will include security and unstable sources,
pin to testing, and when something breaks, investigate the situation and
specifically install the fix from unstable:
# apt-get install -t unstable <fixed package list>
The _other_ situation to keep in mind is that specific changes which
have deep and wide dependencies often are kept _out_ of testing for
considerable periods of time. KDE, GNOME, and glibc changes are among
these, and in all three, testing can lag unstable not by days, but by
months. This can be difficult to explain.
Or in short: Debian offers a *very* high degree of flexibility in
selecting a balance of currency *and* stability, above and beyond the
nominal levels provided in the official release levels.
Trying to explain this to the new Debian adoptee, lacking experience
over some time with Debian's packaging system, and a clear understanding
of Debian Policy, is very, very difficult. Hence the basic advice:
When starting out, choose stable (if your HW and needs will allow it),
or stick to testing for a while, and keep a weather eye out for
security updates.
> > ... unstable (usually works, but watch the release notes /
> > upgrade lists), experimental (unofficial, *will* stab you in the
> > face, given the opportunity. My basic recommendation is
> > 'stable' for servers, 'testing' for workstations,
>
> Is this still your recommendation? I've used testing in the past for
> workstations, but from the recent discussions thought that unstable
> would be the preferred choice when stable won't cut it.
What you (and all others out there) have to keep in mind is that
unstable *will* break. It changes. Daily. And some of those changes
will break things. You're not going to get any more than a few hours
advance notice of this if you're tracking unstable. Versus the
week-and-some which 'testing' affords.
...and by contrast, the *only* changes to 'stable' are updates which
address bugs and security issues. For an organization which values
stability of operation, the ability to track a highly consistent version
of tools for a 2-3 year interval (the typical period between major
Debian version releases, plus support of the prior release) is valuable.
Especially as you can *also* simultaneously track the development
version for compatibility and future-proofing purposes, should your
organization have the minimal neuron count to realize this is not only
valuable, but mandatory.
> > until you understand packaging tools. After which point you
> > want to look at pinning.
>
> I'll have to look into pinning. I prefer running stable, but want
> some packages not available there.
Basically (all file locations in /etc/apt/)
- In apt-preferences, set your default pin levels.
- In your sources.list file, include both your default pin release,
and other releases to allow specific installations.
- In your apt.conf file, set the cache-limit high enough to prevent
the dreaded mmap error.
Locally, I track testing by preference:
[karsten@superego:apt]$ more apt.conf preferences
::::::::::::::
apt.conf
::::::::::::::
APT::Cache-Limit "25165824";
Acquire::cdrom::mount "/mnt/cdrom";
::::::::::::::
preferences
::::::::::::::
Package: *
Pin: release a=testing
Pin-Priority: 950
Package: *
Pin: release a=stable
Pin-Priority: 750
Package: *
Pin: release a=unstable
Pin-Priority: 400
To install a specific *nondefault* release package or packages:
# apt-get install -t <pin level> <package list>
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Save Bob Edwards! http://www.savebobedwards.com/
Attachment:
signature.asc
Description: Digital signature