Due to constraints I cannot efficiently control, I opted to use Debian Testing. How do I exclude SID packages from infiltrating into my system?

Are you being purposely mysterious.
Just don't ask for any. You do that with your sources.list (/etc/apt/sources.list). If you don't have any Sid repos then you can't get any Sid packages. You realise, I hope, that all Testing packages were once Sid packages. But if you've used Debian since 2005 I would have thought you knew all that???
jdk

Interpreting the OP as purposely being mysterious, definitely, depends on the reader's state of mind. In the case of an unstable mind, that can easily be the case.

I am asking because I learnt that it can be done, and because Testing is in effect Testing/Sid by default, and there is no need to consciously include "sid" in /etc/apt/sources.list. The technique is related to pinning, but I have never used it, and that is the purpose why I asked here.

A simple indication as to what I should read to understand what I should do and what it entails, also know as an RTFM, is enough for me.


Thanks.

Sorry but I thought Testing is Unstable.

I am reading about "apt pinning", but the prospects are not so attractive to anyone wanting a stable system from the point of view that it wouldn't include any SID packages.

Please note, that "stable" above is used in a different sense than what it is usually intended to mean by Debian.

I want to prevent a Debian Testing installation from automatically pulling in packages from SID. This, obviously, if this setup is possible.

Testing is not Sid.
Testing will not install any packages from Sid repositories unless you add some lines to your sources.list to include Sid repositories.
So, the answer to your question is that you do not have to do anything to stop Testing from installing Sid packages as it will not do that.

Calling something Jessie/Sid does not mean that Testing and Unstable are the same. They each have their own repositories. I stated this in my first post. You cannot get a Sid package into a Testing box via normal means (using apt-get or aptitude) if you don't have unstable repos in your sources.list file. To get an unstable package in a Testing box you need to:
1. Have unstable repos in your sources.list file
2. Have a preference file that looks something like this:
3. Use a special switch in aptitude or apt-get like this:
So you can see it's very hard to imagine all this happening by accident. The only automatic (w/o asking you) installation of unstable package would be upgrading those that you have already chosen as the unstable versions you wish to use. Nothing accidental about this at all.
jdk

If your sources are tracking testing, then you won't get any packages from unstable...

So, it means I should retain my current configuration.

and

You will only get updates meant for Jessie if that is what you mean, yes.
Since you are tracking a release that is currently testing you will, however, get things like kernel version updates if you run dist-upgrade regularly (which most people who want to track Testing will do).

You get kernel upgrades (called "linux-images" by Debian) the same way you get upgrades of any other package. I never use "dist-upgrade" but only "safe-upgrade" and that certainly doesn't prevent kernel updates from happening.
jdk

I was under the impression that all you got were updates to the current kernel, bugfixes and the like, not upgrades to a different version of the kernel? (For example Sid just changed to the 3.8 branch -- I had thought you would only get that kernel if you dist-upgrade)

In testing and unstable, you will get new kernels when they become available if you have the kernel package installed - e.g. linux-image-686-pae

This is a meta package which will always install the latest 686-pae kernel from the repos (as a dependency) when updated.

Debian stable kernels do not get version upgrades, only bug fixes - so stable users will not see any new kernels. This means if they want the latest LTS kernel (3.4) in place of 3.2, they'll need to build it.

Ah, thanks, I'd not realised that any packages were upgraded to higher versions without a dist-upgrade.

You'll also recall that the linux kernel numbering system was changed a couple of years ago. Before then a change from kernel 2.4 to 2.6 was a major change. Today a change from 3.5 to 3.8 is not so momentous.
jdk