[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What are the dangers of using packages from both stable and testing?



On Fri, 30 Jul 2004 22:34:37 -0700
listcomm@ml1.net wrote:
>
> > > What are the dangers of using packages from both stable and testing?
> 
> Okay...  I got told by someone on this list: (a) that it is system
> suicide,
> and (b) that the fact that it is system suicide is well-documented in
> many places with ample dire warnings in 384 languages including Martian.

That was almost certainly me (although I didn't mention 384 languages
nor Martian -- probably more like 128 and Lakota Sioux).


> But I haven't been able to find any such warnings yet, and nobody
> answered my "Where does it say that?" question.

I'm sorry I dropped this conversation earlier.  I haven't been paying
as much attention to this list as I used to -- just way way WAY too
much traffic on it these days, and I can't keep up.  My memory
was that both the Debian Reference and the apt HOWTO address this;
but apparently my memory isn't very good, because I went and looked
just now, and I cannot find the warnings I remember in either.
People get warned away from mixed stable/testing or stable/unstable
systems here on the list with some regularity; but while I'm pretty
sure I read "You Are Recommended To Not Do This" warnings in some
piece of Debian documentation somewhere, I sure can't find it; and
if I can't find it, it's hardly fair of me to give you a hard time
for not finding it either.


> One thing I *am* certain of, is that if you are running one release,
> the risk increases proportionally with the number of additional
> other-release packages that get sucked in with whatever you tried to
> load from  the other release.  However, even so, it only takes *one*
> infernal incompatibility to land you back at the command prompt with
> X11 whining like a bad alternator bearing, or worse yet trying to
> resurrect your system via CD-ROM...

Right.  The usual sequence is this:  someone is running stable; they
fetch packages from testing or unstable; things work fine; they do it
again; things work fine; they try to do it again, and run into a
problem associated with a library incompatibility.  The best way that
this can play out is for the package management front end being used
to tell them "if I install this, I'm going to have to remove these
other packages too", so the user has a chance to either say "no no no"
and not end up with a system missing software they need, or can choose
to also install *those* packages from testing/unstable, or whatever.
Of course, some users ignore such messages or just hit "y" to
everything; but then, well, it's their fault when they need something
that's no longer there.

But that's the best way it can play out.  The worst way -- which is
thankfully uncommon, but can and does happen -- is if Depends or
Conflicts don't catch the problem.  An example: package A in stable
requires libfoo version 2.4 or greater; user installs package B, which
requires libfoo version 3.1, and so that gets brought along, replacing
v2.4; package A isn't marked for removal because 3.1 > 2.0; but
software compiled against libfoo v2.4 chokes with libfoo v3.1, and so
the binaries in package A are now broken).  The package manager for
libfoo can't set Conflicts: for *everything* compiled against earlier
versions of libfoo because libfoo is just too commonly used.  And if
this happens with something like glibc, you're hosed.

-c

-- 
Chris Metzler			cmetzler@speakeasy.snip-me.net
		(remove "snip-me." to email)

"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear

Attachment: pgpd5BQQM1RN0.pgp
Description: PGP signature


Reply to: