[vox-tech] Installing subversion from sid into a sarge box

[Rick Moen]

Quoting Jay Strauss (me at heyjay.com):

> >However, I'm always surprised at people saying they want to be on the
> >testing track prior to release, but not afterwards.  Why is that track
> >desirable today, but not after sarge's relese?
> 
> I just want the newer stuff, Perl primarily.

You might want to track "testing", then.  More below.

> And since sarge is almost "stable" seems to be the right dist for me.

It's possible that there's a bit of lingering confusion, so please
pardon my going didactic (er, more didactic ;-> ) on you for a while:


The Debian branches named for Toy Story characters (buzz=1.1, rex=1.2,
bo=1.3, hamm=2.0, slink=2.1, potato=2.2, woody=3.0, sarge=3.1, and the
planned etch branch that isn't yet extant) are _starting points_ --
installable package ensembles -- for Debian systems.  Absent special
circumstances I can't think of at the moment, one would ordinarily want
to install one of those that's in reasonable condition and useful at the
date you're doing this (i.e., avoiding installing buzz/1.1 in 2005).
Absent special circumstances, you would from that point forward want to
choose how far away from the bleeding edge you want to be, and keep
tracking that distance.

Here's the thing:  Remaining on "woody" after release (as you seem to
intend) means _not_ staying the same distance from the bleeding edge.
You probably don't want to do that.  I'll detail why:

At any given time, the package ensemble (branch) that's in best shape
for running absolutely reliable systems has symlink "stable" pointed to
it.  The later branch gets symlink "testing", and receives all packages
newly uploaded by package maintainers, after filtering by automated
quarantining by scripts that check new packages uploads against certain
quality criteria.  

I refer to stable and testing -- functional names indicating current
distance from the bleeding edge, and thus continually getting newer
replacement package versions -- as "tracks", to distinguish them from
the Toy Story-named "branches", whose names designate installable
package ensembles that were put together at some fixed point in time.

It's also possible to get raw access to new package uploads without
quarantine delay:  This is branch "sid", which also bears permanently
assigned track name "unstable".  (Thus, testing is defined as unstable,
net of package quarantining.)

At some point in the future (release day), woody/3.0 will get mothballed
(losing the "stable" track symlink, which will be repointed towards
sarge/3.1).  A new branch will open up, called etch, which will get the
"testing" branch symlink.  And of course the "unstable" symlink will
remain pointed (as always) at sid.

After that day, systems that are set to track "stable" will smoothly
transition, the next time the users gets package updates, from woody/3.0
package versions to sarge/3.1 ones.[1]  Systems set to track "testing"
will transition even more smoothly from sarge/3.1 package versions to
etch ones.  In both cases, the systems affected will _remain_ the distance
away from the bleeding edge that the admin has decided is desirable.
This is A Good Thing.


If you define your system's default branch (in /etc/apt/[whatever]) to
be "testing", you're saying "please keep me a few steps back from the
bleeding edge, in retrieving package updates".  If you define it to be
"stable", you're saying "I'm extremely risk-adverse and/or short on
download bandwidth, so I want only extremely well-tested versions of
everything and don't mind using relatively antique versions".

Setting your default branch to "woody" means neither of those things.
It means "I want the bleeding edge today, _but_ I want to switch to
inhabiting the extremely boring stable-package doldrums starting the day
the symlinks change, _and_, later on, I want to switch to using
all-unmaintained software starting with the next symlink change
after that." 

> I'll continue on sarge for a while (couple of years, I figure) once it
> goes stable.

I hope (with the above background), my rhetorical question about this
intention is now clearer:  Why would you want to be close to the
bleeding edge today, but suddenly switch to antique, ultra-stable
software starting the day of "sarge" release?  

My point is that you're, in effect, _jumping tracks_ if you do that.
Absent some compelling reason, that's probably not in your interest.

I hear a lot of people say they want to do it, and can't help thinking
it means they're a bit fuzzy on how the maintenance system (and
"tracks") work.  In many cases, it may be because they're not used to
using a distribution with an ongoing maintenance regime, designed to
eliminate the need to ever reinstall or have system downtime during
upgrades to new distro versions.  With Debian, you _don't do_
distro-version upgrades.  You don't need them:  You just keep getting
new packages to stay your preferred distance away from the bleeding edge
(thus:  stable, testing, or unstable).

I hope that helps.

[1] Many admins will not even notice the changeover.  That changeover
_does_ introduce considerably more package updates, the first update
sessios following release day, than normally is the case on the stable
track:  It's the job of the Debian Release Manager to make this bump be
as smooth as possible, and release day is supposed to be timed to
minimise the likelihood of glitches.

Release day is basically unnoticeable to those following the "testing"
track:  They get a gob of package updates, the same as always.

-- 
Cheers,                                      Hardware:  The part you kick.
Rick Moen                                    Software:  The part you boot.
rick at linuxmafia.com