Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'd like to install uwsgi on my Debian server. This package wants to upgrade some core packages:

  • libc6 from 2.11.3-3 (now, stable) -> 2.13-35
  • initscripts from 2.88dsf-13.1+squeeze1 (now, stable) -> 2.88dsf-13.3

Can I do this safely, or is there a way to install this package without upgrading libc6? I have the following in the /etc/apt/preferences file:

Package: *
Pin: release a=stable
Pin-Priority: 1001

Package: *
Pin: release a=testing
Pin-Priority: 60

Package: *
Pin: release a=unstable
Pin-Priority: 50

Package: fabric
Pin: release a=unstable
Pin-Priority: 2000
share|improve this question

2 Answers 2

up vote 2 down vote accepted

It's fine to install, and mixing stable/testing is usually fine -- that's what dependencies are for, to make sure that everything gets the versions they need.

Gilles is incorrect: testing does get security updates. See "How is security handled for testing?" in the Debian FAQ for details. You may need to adjust things like the unattended-upgrades configuration if you want them installed automatically.

However, your /etc/apt/preferences will cause problems with a mixed stable/testing system, because you've set the priorities way too high. Read the apt_preferences(5) man page carefully, particularly under "APT's Default Priority Assignments". Basically, setting Pin-Priority: 1001 for stable is saying "install the version from stable, even if it's a downgrade of a package that was installed from testing". Downgrading is generally an unsupported operation in apt, but even worse, this means that any time you try to install a newer version of a package like libc from testing, you'll constantly be running against problems where apt is trying its hardest to reinstall the old version. That will quickly lead to the "conflicts and missing dependencies" that Gilles referred to. On a properly configured system mixing distributions is fine.

The numbers you actually want to use are closer to:

Package: *
Pin: release a=stable
Pin-Priority: 200

Package: *
Pin: release a=testing
Pin-Priority: 80

Package: *
Pin: release a=unstable
Pin-Priority: 50

The key is that stable should be set between 100-500, and testing should be between 1 and 100.

share|improve this answer
    
Thanks for the detailed explaination of /etc/apt/preferences and offering some options. I'll look into this –  vdboor Aug 13 '12 at 8:54
    
"mixing stable/testing is usually fine" -- the advice I usually hear from Debian developers directly contradicts this statement. As soon as you try to install something from testing that requires a newer libc or glib, you're going to effectively drag in half of testing with whatever you're trying to install. This is a bad idea; backporting packages is the recommended approach. –  cdhowie Oct 10 '12 at 16:02
    
I still stand by my statement. Dragging in newer packages is acceptable to me, when the dependencies require it. Timing matters quite a bit; for example, testing is currently in a freeze and is getting closer and closer to what will be in the next stable release. Anyway, the distinction between backports and pulling a package from testing is whether or not you think running testing is a good idea. It does not change the fact that mixing stable and testing is safe (as safe as testing itself). –  Jim Paris Oct 10 '12 at 16:29

It looks like you're trying to install a package from the testing distribution on a stable installation. This almost never works, because the testing packages will pull in a lot of libraries and other packages from testing. You'll end up with a mixed stable/testing system, which is harder to maintain than pure testing because you'll encounter more conflicts and missing dependencies. Remember that testing doesn't get security updates as quickly as stable, it's a bad idea to use it on a server.

If you need one specific package that isn't available on stable, such as uwsgi, I recommend compiling it from source. Often, recompiling the source on stable will work; the minimum library dependencies in the package are generated based on the versions of the development packages you have installed. Alternatively, you may look for a backport: a package from testing that has been recompiled for stable.

In the case of uwsgi, there is no official backport but there is an unofficial one. It appears that compiling from source requires a few minor modifications and a libjansson backport. Remember that, whether you compile from source or use someone else's binary, you will not get security updates, so watch for security announcements upstream.

share|improve this answer
    
Seems like a good option to consider, if all fails. It seems doable especially with uwsgi. I do like to try the testing solution first, letting the package manager doing it's job. :) –  vdboor Aug 13 '12 at 8:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.