Quoting Jay Strauss ([EMAIL PROTECTED]): > >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. [EMAIL PROTECTED] _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech