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

> > 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).
>
> 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

> 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.

Chris Metzler

> 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

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.

viz

> This scenario is always a bug in libfoo for breaking backwards
> compatability without changing its soname, and Debian has plenty of

Yeah. It still happens, though, viz. getting bit by #241360.

Chris Metzler

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.

greg