l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
January 6: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2006 Jan 16 09:35

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
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 (scofield@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.

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.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.