Re: What are the dangers of using packages from both stable and testing?
On this revelational Saturday, of the seventh month of 2004 you wrote: > And if this happens with something like glibc, you're hosed. Okay, I just happen to be the poor sod you were referring to in this nugget I found in the archives of just three months ago. What's worse is that my carelessness was just confined to an accidental one stable line in my sources.list in my otherwise purely sid distro. Now I've got libglib1.2 and libglib2.0-0 handling different packages. I guess I put too much confidence in aptitude to catch any package mixing. I'm also somewhat fortunate that uninstalling 1.2 only blows away about half of my packages instead of all of them. Yet even after removing 1.2 and trying to install the packages that WERE dependent on 1.2, hoping that they'll assume the already installed 2.0-0 dependencies, neither apt-get or aptitude have enough wisdom to recognize it. They still try and install 1.2 when using apt to reinstall them. So question is, is there a way to strace what packages and why the packages i'm trying to reinstall to depend on 2.0 are trying to pull and install 1.2? Or, another method I'm wondering about whether if it's safe for me to install glibc1.2 into /usr/local and if there is, whether there's a way to do this way apt or dpkg without having to compile it. That could be a temp quickfix although ideally I want everything depending on 2.0 without potential 1.2 liabilities like this happening again. Any advise would be greatly appreciated. A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What are the dangers of using packages from both stable and testing?
On Sat, 2004-07-31 at 18:02 -0400, Silvan wrote: > On Saturday 31 July 2004 10:52 am, Carl Fink wrote: > > BTW, using information from > > > > http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html > > > > section 6.14, you can quite easily recompile a Sid package using the Woody > > libraries to run under Woody (unless the program requires actual features > > not available in the older libs). > > Which a vast heaping many of them probably do. Woody is 40,000 years old, and > developers don't like to be constrained to features that were only available > when mankind was first taming fire. Not when there's some new API call that This is nice speculation I suppose, but in practice, I have not run into any packages that can't be compiled on woody, and only a few that required a whole lot of supporting packages to be backported. The folks over at backports.org certainly seem to have been able to backport a good many packages. -Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What are the dangers of using packages from both stable and testing?
On Sun, 1 Aug 2004 15:59:52 -0400 Joey Hess <[EMAIL PROTECTED]> wrote: > > Chris Metzler wrote: > > 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. > > This scenario is always a bug in libfoo for breaking backwards > compatability without changing its soname, and Debian has plenty of > standard ways to deal with it that don't involve conflicting with lots > of packages. If you see something like this, file a bug report. Yeah. It still happens, though, viz. getting bit by #241360. -c -- Chris Metzler [EMAIL PROTECTED] (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 pgpfguEESvWPu.pgp Description: PGP signature
Re: What are the dangers of using packages from both stable and testing?
Chris Metzler wrote: > 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. This scenario is always a bug in libfoo for breaking backwards compatability without changing its soname, and Debian has plenty of standard ways to deal with it that don't involve conflicting with lots of packages. If you see something like this, file a bug report. -- see shy jo signature.asc Description: Digital signature
Re: What are the dangers of using packages from both stable and testing?
On Saturday 31 July 2004 10:52 am, Carl Fink wrote: > BTW, using information from > > http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html > > section 6.14, you can quite easily recompile a Sid package using the Woody > libraries to run under Woody (unless the program requires actual features > not available in the older libs). Which a vast heaping many of them probably do. Woody is 40,000 years old, and developers don't like to be constrained to features that were only available when mankind was first taming fire. Not when there's some new API call that combines a kitchen sink with a microwave oven and a motorcycle, and all it takes to get it is to force everyone to upgrade libflummy to the latest CVS version. -- Michael McIntyre Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What are the dangers of using packages from both stable and testing?
On Fri, 30 Jul 2004 22:34:37 -0700 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (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 pgphyJ8yj6R2f.pgp Description: PGP signature
Re: What are the dangers of using packages from both stable and testing?
BTW, using information from http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html section 6.14, you can quite easily recompile a Sid package using the Woody libraries to run under Woody (unless the program requires actual features not available in the older libs). -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What are the dangers of using packages from both stable and testing?
On Sat, 2004-07-31 at 01:34, [EMAIL PROTECTED] wrote: > > > What are the dangers of using packages from both stable and testing? > [...] > (Nonetheless, I'd still like to know where all the fabled and legendary > DON'T DO THIS warnings are) (especially the one written in Martian) Well, to be honest, it is called evolution... where the strongest survive. Go ahead... we need to thin the herd quite a bit, so let us not waste anytime. Oh, btw, it isn't Martian, it is Venusian. The Martian translation is being worked on by an MIA Debian Developer... What it really comes down to is this: Woody, is based on glibc6 2.2.5 (I think), where as currently Sarge and unstable have glibc6 2.3.2.ds1. Also the target compiler used for woody was version gcc 2.95.4. Testing/Unstable are currently targeting gcc 3.3.4. These 2 very important reasons are the reason why mixing of Woody, Sarge and Sid is a bad idea. Now mixing of Sarge and Sid (right now) is a reasonable thing to do, but still not recommended. Reason being they are using very similar underlying libraries and compilers. Woody, would more than likely implode upon itself, rendering it useful as a doorstop, after the catastrophic event happens. But, you can try it if you want. But, just make sure you are wearing the proscribed Lead lined Kevlar reinforced Nomex Fire suit, to weather the calls from your users. Luck. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: What are the dangers of using packages from both stable and testing?
> > 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. But I haven't been able to find any such warnings yet, and nobody answered my "Where does it say that?" question. 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... (Nonetheless, I'd still like to know where all the fabled and legendary DON'T DO THIS warnings are) (especially the one written in Martian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What are the dangers of using packages from both stable and testing?
On Thu, Jul 29, 2004 at 04:57:57PM +0200, Jacob Friis Larsen wrote: > What are the dangers of using packages from both stable and testing? You might want to look at http://backports.org, which contains many of the Sid packages backported for use with Woody. If that doesn't work, you might use apt's ability to download source packages and just recompile it yourself, to work with the Wooody libraries. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What are the dangers of using packages from both stable and testing?
What are the dangers of using packages from both stable and testing? Thanks, Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
