Re: don't upgrade! libpam problem!
On Wed, Jun 27, 2001 at 01:43:18AM +0200, Emmanuel Charpentier wrote:
> [ To be fair, the speed with which the bug has been fixed and 0.72-27
> made available is also charcteristic of free software processes. ]
to be even fairer, in any development environment (even commercial
development) it is common for someone other than the developer to do the
testing - for example, other programmers and beta test teams.
any user of debian unstable is inherently part of the debian's beta test
team.
> I wonder how much people have been permanently locked out of their
> *only* machines by this shortsightedness ... Has someone an idea on
> how to count them ?
excrement occurs. unstable is called "unstable" for a reason. if you
can't tolerate any risk of broken packages then don't use unstable. if
you're willing to take a small risk of catastrophe in exchange for new
and updated packages, then go ahead and use unstable.
the safe way to use unstable - even on production machines - is to test
all upgrades on unimportant machines first. e.g. your workstation that
happens to run the same packages as your important servers (a system
admin should be doing that anyway as it's the best way to experiment
with stuff before implementing it on a live server).
i got bitten by this myself this morning. i fired off a bug report and
downgraded to the previous version (fortunately, i never do an upgrade
without at least two root sessions open - one to do the upgrade and one
to diff any config files vs the .dpkg-new version if necessary). problem
solved.
then i bothered checking and noticed that the bug had already been
reported several times AND fixed (i should have checked before sending
off my bug report)
the most significant thing from the incident is that i have to wait a
few days (at most) until i can upgrade any of my servers. big deal.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: