Re: Unstable packages on Stable distr.
Terry Hancock <hancock@earthlink.net> wrote:
>The reason is that the unstable packages seem to have the assumption
>built into them that they will never be used on a stable distr system
>-- that is they have dependencies on later versions of basic packages.
Consider this for a moment; how should unstable packages - that is, the
packages that will become the next stable release - ever use new
features of packages in the base system if they aren't allowed to use
anything except what was in the *last* stable release? If you mix
packages from different distributions, the maintainers of those packages
will not break things unnecessarily, but in the end you're on your own.
>In many cases these seem to be frivolous assumptions. It seems very
>implausible to me (for example) that compiling libsdl1.1 _really_
>requires libc6 >= 2.1.97. I'm pretty sure that, installing from
>source, libc6 version 2.1.3 (in Debian 2.2) will work. So why this
>dependency? This appears to exist only to force using the unstable
>distribution throughout -- not because the software would actually
>require it. (?)
Blame the libc6 developers, not Debian. A program compiled against libc6
2.2, or one of its pre-releases, simply will not run with libc6 2.1. Try
it and see; it was the first thing I tried after upgrading to libc6
2.1.94.
Shared library dependencies are dynamically generated when the package
is built, and the maintainer of the shared library package specifies the
minimum version that is *binary*-compatible. We don't do
binary-incompatible changes just for the sake of it, and we certainly
don't randomly force people to upgrade unnecessarily. However,
binary-compatibility is not the same as source-compatibility. There are
separate Build-Depends: fields in source packages that specify the
minimum source-compatible versions of the necessary development
libraries.
>And this happens all the time. But if libc6 2.1.97 is defined as an
>_unstable_ package, is it going to break my stable distribution? Is it
>buggy? It should just differ by a patchlevel, right?
Er, glibc 2.1.3 to 2.1.97 is somewhat more than a patchlevel. :) 2.1.97
was a pre-release for glibc 2.2; unstable is now on glibc 2.2.2, but
that's binary-compatible with 2.1.97, as the dependencies indicate.
'unstable' really means 'changes often', not 'will break'; it shouldn't
be overly buggy, but it comes with no assurances whatsoever that it'll
work.
>So, how have people done this before? Is it possible to run a mixed
>box like this, or am I just out of luck? I suppose I could just
>acknowledge that I'm going to have to install development packages from
>source -- but if so, why have the development packages at all?
If you don't want to upgrade things like libc6, you could always try
downloading the Debian-patched sources (try 'apt-get source <package>')
and building binary packages from them on your system. You need at least
dpkg-dev and devscripts, plus whatever build-dependencies are necessary
(assuming that you already have things like make, gcc, and g++).
You might also look at the 'testing' distribution. This is designed for
people who want a reasonably bug-free distribution but who don't want to
be too far from the bleeding edge, and is generated automatically from
the set of packages that meet certain bug-free-ness and consistency
conditions. It's actually what will become the next stable release.
>Thanks for any suggestions. Please reply direct or CC me.
Cc'd as requested.
Cheers,
--
Colin Watson [cjw44@flatline.org.uk]
Reply to: