Re: Before going with debian questions.

From: Karsten M. Self (kmself_at_ix.netcom.com)
Date: 04/18/04

  • Next message: Karsten M. Self: "Re: festival 1.4.3 is not working on debian testing"
    Date: Sun, 18 Apr 2004 14:48:07 -0700
    To: debian-user@lists.debian.org
    
    
    

    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/
    
    

    -- 
    To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    


  • Next message: Karsten M. Self: "Re: festival 1.4.3 is not working on debian testing"

    Relevant Pages

    • Re: Running testing? -- read this.
      ... I'm just an average Testing user, have been for a while, and around me almost every Debian users I know are using Testing, mostly because it's the Debian's flavour which can compare with other distros in term of being usable on a reasonably new computer, with up-to-date softwares. ... be considered a developer-only version, and according to my experience (i use it for work, along with Ubuntu stations... ... better still (it has NEWER packages!), but Unstable must not work well, ... You will also get the pleasure of finding all the bugs, ...
      (Debian-User)
    • Re: update in sid has killed gnome-terminal
      ... worked through most of the Debian problems too. ... adept at making Debian packages but every now and then a problem occurs ... discover bugs and fix the bugs if they have the expertise (but ... The Open Source Business Network in SA ...
      (Debian-User)
    • Re: Gentoo and Debian (one of those "which distro?" topics).
      ... > Gentooo's packing manager is much like FreeBSDs, ... Remember that there are three concurrent version of Debian. ... latest-and-greatest, bleeding-edge packages. ... you're prepared to deal with bugs in order to have the latest of everything. ...
      (comp.os.linux.misc)
    • Re: Need newer software that included with stable (that isnt at backports.org)
      ... only get security updates. ... All the security updates are served through ... Consequently, fixes for packages ... The Debian ...
      (Debian-User)
    • Re: apt-listbugs and security
      ... What am I to do with the bug reports I regularly ... I installed Debian Sarge because I am a relative ... of grave and critical bugs with many security critical packages such as sudo, ...
      (Debian-User)