Rick Moen wrote: > Quoting Bob Scofield ([EMAIL PROTECTED]): > > >>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.
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 testing: 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. --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
