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. > 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" ;-> ). _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
