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:
pgpicV5lmBT2l.pgp
Description: PGP signature