On Sun, Jun 20, 2004 at 11:13:37AM -0500, Michael Satterwhite wrote:
| I've been watching the various discussions on this, and note that most
| experienced types think that the unstable distribution is better than the
| testing distribution. This leads me to one more question / observation
Unstable is better in the sense that it has the latest-and-greatest
software. Fixes and features arrive just as fast as the package
maintainer can upload them. Testing has to wait at least two weeks,
sometimes longer, to receive those same fixes and features. Sometimes
a problem in a package doesn't get noticed until it arrives in
testing. If the maintainer uploads a corrected package five minutes
after the first user reported the bug, testing will still have the
broken package for at least two weeks until the fixed package is
migrated from unstable. It is a set of tradeoffs with no clear
absolute "better".
| A few weeks ago (I don't know about now), the KDE distribution in unstable
| simply would not run. I've noted several of the messages recommending the
| unstable branch say that there were some updates that caused the receiving
| machines to crash / lock / not start.
Fun. ;-)
| How does one recover from something like this short of doing a reload?
That depends on the exact nature of the problem. In short it comes
down to understanding the system, tracking down the problem and
arranging some sort of solution or workaround.
For example, sometimes an install fails due to the postinst script
having a bug or just not handling some situation optimally. Editing
the postinst script to avoid that error is a way around the problem in
that situation. Other situations (like the bad PAM package upload a
couple summers ago) are resolved by booting without init (append
init=/bin/sh to the kernel command line) and manually starting enough
of the system to install the previous version of the package so
authentication will work when you reboot the machine. Sometimes the
issue is simply one of dependency resolution or
incorrect/missing/insufficient dependencies in the package. That
problem is resolved by determing which package(s) need to be
installed, upgraded, or downgraded.
| For that matter, a reload should crash the same way as it's getting
| the same software.
That depends on the source of the problem. Sometimes installation on
a clean system works but upgrading an existing system fails to handle
certain situations. Sometimes it is the other way around. Again, it
all depends.
| I may be missing something - quite likely, BTW, I'll admit total
| ignorance here - but it would appear that it wouldn't take many of these
| incidents to make the testing branch seem A LOT better than unstable.
|
| Other than this, the arguments for the unstable over testing seem valid.
Personally I run a mixture. Testing has somewhat of a safety net to
protect against certain sorts of problems. However, sometimes a
certain package or version is only available in unstable. With my
level of experience I feel comfortable trying unstable packages and
dealing with any hurdles I may run into. However, if you don't have
that level of experience and don't have a mentor close by to help you
through those issues then I would recommend using testing. At the
same time, follow various mailling list discussions, and read stuff on
the web, read various files (docs, source and scripts) in packages and
build up the experience and knowledge to be comfortable in the face of
potential failures. It also helps if you have more than one machine
so you can try something on one machine and if it doesn't work then
don't do the same thing to the other.
-D
--
"He is no fool who gives up what he cannot keep to gain what he cannot lose."
--Jim Elliot
www: http://dman13.dyndns.org/~dman/ jabber: dman@dman13.dyndns.org
Attachment:
signature.asc
Description: Digital signature