Re: [vox] /etc/apt/sources.list --- testing -> woody?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox] /etc/apt/sources.list --- testing -> woody?
Quoting Peter Jay Salzman (email@example.comMAPSrg):
Apologies for breaking threading. I accidentally deleted the prior
post, and had to grab its text from the archive.
> it sounds like you want to keep your sources list at "testing". once
> woody uses the stable pool, what is *now* called sid will be given a
> new name and assigned the testing pool. this will ensure your system
> is "almost" bleeding edge with relative safety. i can recall only a
> couple of times that a package in woody was "broken". but it was dumb
> stuff. a file conflict between lesstif and openmotif and a dangling
> symlink that got installed by yadex. i think i recall ispell being
> screwed up for 2 weeks. can't think of anything major.
One of the other areas where commentators tend to miss the point about
Debian, I've noticed, is in assuming that any broken package uploaded
for any length of time affects everyone. This is partly because they
haven't thought through the administrative process, and partly because
they're accustomed to "kitchen sink" installations.
Let's assume the maintainer of the lesstif package uploads a package on
January 1, 2002, that accidentally treads on some file also provided by
the openmotif package. It immediately gets listed in the unstable = sid
Every night, a script runs that attempts to determine what new packages
in unstable should also appear in testing. (For purposes of discussion,
let's assume that the initial package-evaluation ruleset for this still
applies. As I mentioned, it's been refined since then.) The package
gets checked to see if it's been in unstable for at least 14 days. If
so, it gets test-compiled automatically on all ten supported CPU
platforms. If there are no errors, then the package appears in testing.
All 1000-odd package-maintainers follow the debian-devel mailing list,
and run the unstable branch on their development machines. Our lesstif
maintainer thus has a 14-day period's worth of list traffic to hear
about his boo-boo from fellow developers and the Debian Bug Tracking
System, before the package hits "testing". If he noticed his error,
he'd either remove the package or upload a fixed version. Either would
prevent the package from hitting "testing", if done with 14 days. (So
would a build failure on any CPU platform.)
A problem package that sneaks by into "testing" is then _potentially_
installed by _some_ people running Debian-testing (until replaced or
removed). That is, _nobody_ runs any sizeable fraction of testing's
more than 8000 packages: There would be no point in trying. (My most
overstuffed Debian-testing workstation box has 814 packages.) You don't
need to go for the kitchen sink because any package you need plus its
dependencies can be added at any time using a one-line "sudo apt-get
install foo" action (drawing packages from either on-line package
mirrors or your CDs, as you prefer) -- or even more easily using
So, the only Debian-testing hosts _potentially_ exposed to the
problematic lesstif package after its 14-day quarantine will be those
where lesstif is actually installed -- which isn't many, you'll note,
and only relatively obscure packages like lesstif are likely to ever
have so little oversight that they escape into testing with even minor
Last, just because a problem package makes it into "testing" on the
mirror sites and you happen to have a version of it installed does _not_
mean you're necessarily going to retrieve and install the problem
version. On January 15, in our example, the problem package became
available. Let's say that on January 31, the maintainer notices his
gaffe and removes or replaces it in Debian's package pools. Would
you, a sysadmin who uses lesstif, have received the problem package?
Only if you _happened_ to have resynced to the current "testing"
packages during that Jan. 15-31 window. Before or after, no.
Last, some might wonder what effect such a glitch has, _if_
you're using that software, _if_ a package with that defect
makes it into "testing", and _if_ you happen to pull it down
before it gets yanked or replaced: You see a message saying one of the
packages you're trying to update wants to alter a file from a different
package, and go back to the prompt. If you're lazy, you can go off and
try again a few days later, giving the package maintainer a chance to
replace it. Or, resubmit your apt-get command with a
"--force-overwrite" option. Either way, the glitch goes away.
In extreme cases of apt-get problems (which would normally occur only
while tracking "unstable"), you open /var/lib/dpkg/status, which is the
package database (an ASCII file), search to the package's entry, and
snip it. Now, the problematic record is gone from the package database,
and you can put in whatever version you want.
I hope this helps put things in perspective.
By the way, I know you were speaking loosely, but I thought I'd
mention for clarity's sake that there _is_ no "stable pool". There's
only one pool package tree, period. It's where all actual package files
live, and all Debian branches point to particular packages in it, which
is how they're defined.
Cheers, "Transported to a surreal landscape, a young girl kills the first
Rick Moen woman she meets, and then teams up with three complete strangers
firstname.lastname@example.org to kill again." -- Rick Polito's That TV Guy column,
describing the movie _The Wizard of Oz_
vox mailing list