Re: [vox-tech] Debian Net Install Questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] Debian Net Install Questions
Rick Moen wrote:
> Quoting Bob Scofield (firstname.lastname@example.org):
>>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:
> 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.
I don't think Debian updates their stable install images between
releases, even just to put new kernels. There are people who create
updated install images as needed, such as this one
(http://tinyplanet.ca/~lsorense/amd64/) for AMD64, where most of the
hardware is so new that things don't work well with the kernel 2.6.8
currently included on official stable installers.
>>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?
Correct, I do use unstable.
In addition to everything Rick mentioned (I'll respond to a couple of
points farther down), there are two good reasons to use unstable over
1) If you're developing software to be uploaded to unstable, you need to
be running unstable (or at least have a chroot running unstable). See my
package at http://packages.debian.org/link-grammar
2) Frequently, transitions going on in unstable can have the effect of
preventing testing propagation for a long time, for example when glibc
was updated between woody and sarge, *most* packages started getting a
versioned dependancy on the new glibc which hadn't propagated because
they were still fixing bugs. This situation persisted for several months
before everything finally migrated over to testing en masse.
> [SNIP a lot of Rick's post]
> 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.)
http://www.debian.org/devel/testing always contains the current rules,
but it doesn't look like they've changed since Rick's knowledgebase post.
> 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.
This was the specific concern I was mentioning. I found that in many
cases, pulling some packages from unstable and most from testing would
make me need to do a lot of work with apt-get to make dist-upgrades go
smoothly. (More work than just running straight unstable) Of course,
those were the days before aptitude, so it may be significantly easier
to sort out such upgrades today.
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
Description: OpenPGP digital signature
vox-tech mailing list