[vox-tech] Debian Net Install Questions

[Rick Moen]

Quoting Bob Scofield (scofield at omsoft.com):

> Debian keeps coming out with newer images every so often.  Suppose one
> has an older image; one that is 6 or 10 or 12 months old.  If one
> wanted to install Debian is there any advantage of downloading the
> more recent image?  It seems to me that the old one should work
> because apt will update everything, right?

Very astute question, Bob.

Mostly, you're right.  One of the attractions of using the netinst images
is that you know that there's not a lot of point is downloading and
housing 11 or so CDs of Debian 3.1 "sarge" packages for each
architecture you care about, when CDs' contents go rapidly out of date,
such that you'll end up downloading newer versions via apt-get of
anything you install from CD.  

The main attraction is newer installation kernels with broader hardware
coverage, e.g. Kenshi's sarge-based netinst with a 2.6.14 kernel, and
some others listed on my Debian Installers page:
http://linuxmafia.com/faq/Debian/installers.html#unofficial

That is, it's little consolation knowing that the Debian mirrors would 
update the software from your aging netinst, if the netinst fails for
lack of, say, adequate drivers for modern Intel ICH7 SATA chips or
certain pestilentially common Broadcom ethernet chips.

> Here's another question.  I got the feeling from a recent post that
> Ken Bloom uses unstable.  Do others use unstable?  Why would one
> choose unstable over testing?

The nightmare of everyone who considers tracking "unstable" is roughly
as follows:

1.  The maintainer of Debian's glibc package gets good and drunk on a
Friday night, completes a software revision, crypto-signs it, and sends
it up to the ftp-master machine.  The ftp-master scripts verify the
signature against the master keyring, pick it up and send it off to the
build hosts, which then populate it into the "unstable" tree in the
package mirrors.

2.  At noon Saturday, the maintainer wakes up, has coffee, gets an
icepack, and starts remembering what on earth he did the previous day.  
At 2 pm, he posts to debian-devel saying "Warning:  Do _not_ get the
current unstable package glibc-2.3.foo.  It's broken.  Will have new
package up imminently."  He also goes onto the #debian and #debian-devel
IRC channels and gets a matching warning posted as part of the /topic.

3.  At 11 AM Saturday, you do "apt-get updates && apt-get dist-upgrade" 
on your server that tracks Debian-testing.  It didn't occur to you to 
consult recent debian-devel postings or the IRC channels for warnings.  

Boom.  (You can recover from that, but it's an annoyance at best.)


Note that, just because someone really dramatically messed up and
released a broken, crucial package doesn't necessarily mean that you as
a person following "unstable" will necessarily receive it.  If in the
above hypothetical, you'd done your apt-get session at 3 PM rather than
11 AM, you'd have missed the window of danger.


To understand why someone might want to be on pure "unstable" instead of
"testing", it helps to understand how "testing" works:  A quarantining
script runs, once per night, doing automated quality checks on packages
newly arrived and (as usual) populated without delay into "unstable".
If they pass those additional automated tests, including compiling
without error on multiple CPU architectures, then each such package
autopopulates into "testing", as well.  If not, not.  (There is also a
minimum quarantining delay, etc.  The ruleset as of 2001 was described
by Jules Bean:  "Testing FAQ" on http://linuxmafia.com/kb/Debian/ . 
Be warned that the exact ruleset has probably changed, but you'll get
the basic idea.)

That quarantining mechanism has some indirect effects:  1. If a package
you want was just now uploaded, it'll not yet be in "testing" purely
because not enough time has elapsed.  This, of course, is a potential
hazard in the area of security fixes   2. Related packages from certain
software suites infamous as "dependency hairballs -- KDE, GNOME, and
Mozilla-derived browsers -- sometimes clear quarantine at different
times, with the result that the current "suite" version is not
installable (at least, as a whole) in the "testing" branch.

I find the mechanism I described earlier -- of following the testing
branch but with optional access to unstable as needed -- lets me fix
those problems.

I track pure "unstable" from some workstations without significant
problems, but it's good to have some experience solving typical apt-get
snags, before trying it (so that those don't seem "significant" ;->  ).