Hey all, I've been doing the same thing the same way, but I would be interested to hear what others are doing and the pros and cons of the various approaches.
Traditionally, I have replaced /etc/apt/sources.list with a universal one that includes stanzas for stable, testing, unstable, and in some cases experimental (for instance on my workstation), and then I place any "extra" repos in /etc/apt/sources.list.d, for instance Debian Multimedia, the various backports, opsview, etc. While this approach has stood me in pretty good stead, I am now setting up puppet in my environment, and am considering my options. I could continue to go with a monolithic sources.list and extra repos in sources.list.d, but while it is nice to be able to do an apt-get -t <release> install <package>, you run the risk of winding up with a "franken-box", with packages from all releases. After a while (several major releases, so we're talking years), you could have issues during upgrades...Though I admit, the process is pretty resilient. The second option is a sources.list that only contains the release for which the box was built. This will limit you in your software selection, for instance, if you want a feature that only recently came out, you either add the repo, putting you in the previous case, or you upgrade lock, stock and barrel to the release in question, which is not always an option. The third option is to dispense with a sources.list altogether, and put release-specific .list files in sources.list.d. Of course, you could have permutations of the above. Did I miss any options? I ask this because I am setting it up to be managed by puppet, but also, I will be upgrading a couple of my workstations to 64-bit capable machines (finally!), and I wanted to decide these details before I pull the trigger. For the record, at present, one of those machines is squeeze and the other is sid. So how do you all roll wrt sources.lists? Thanks, --b
