If you’re using Debian Etch/Testing or Sarge/Stable right now, you’re about to see a change in the Debian APT archives as Etch becomes the new Stable release, and Sarge becomes a legacy release. In fact, this was already supposed to have happened on the Fourth of December, but delays encountered by the Debian core dev teams have pushed it back a bit. Etch is now “frozen”, only accepting compatibility, functionality, and stability fix updates from package maintainers until Etch is moved into Stable. This means that the Stable release of Etch is imminent. Because of this, your software management world might get a little shaken up. There are some simple ways to handle this, however:
- If you’re using Debian Etch/Testing, you could avoid the turmoil that comes with continued use of Testing by following Etch into Stable. You do this by editing your sources.list file (located at /etc/apt/sources.list). When a new release moves into Stable, the previous Stable release moves into legacy support and the Testing branch undergoes a serious shake-up that can result in broken software updates and a wedged APT system, off and on, for a couple months before the new Testing release is fully settled in. I’ve dealt with this in the past, and will not deal with it again. To avoid this problem, and follow the Etch release into the Stable branch, just find all entries in your sources.list file that refer to the testing branch and change the word “testing” so that it says “etch”. Nothing will change now, and you’ll basically never notice the change when it does happen except that you will not see software updates nearly as often in Stable as you did in Testing. If, at a later date, you want to move back up to Testing (when you’re reasonable sure Testing has stabilized), you can then change it back to Testing and do an apt-get dist-upgrade to bring everything up to speed with new software versions. You’re probably better off sticking with the same release version, though, and using apt pinning if you need a specific higher-number version of a given piece of software.
- Similarly, if you’re using Debian Sarge/Stable, you should ensure that any entries in your sources.list file that refer to “stable” are edited to say “sarge” instead. This will allow your system to move gracefully into legacy support, which (if I recall correctly) lasts three years. As I learn more about the GPL, I begin to suspect that the three year number was not arrived at by accident — it’s probably part of a plan to conform strictly to the three-year source availability clause of the GNU General Public License. Similarly to the Testing situation, you may find that you wish to move out of legacy and back into the Stable branch after the version release shakeup settles down. Stable will see considerably less of a shakeup than Testing, but it may still behoove you to wait a few weeks before upgrading from Sarge to Etch. To do so, of course, you can just change your sources.list entries to suit and do an apt-get dist-upgrade when you’re ready.
- Finally, there’s my favorite choice, which I will be using in the near future wherever I find that it’s not an unreasonable burden: do a fresh install of FreeBSD, or whatever else you want to use (the next Debian Stable or Testing version included in the list of options). If you’re following Etch into Stable, there’s really zero need for this, but otherwise you may discover eventually that you’re better off with a fresh install, in part because this will prompt you to be damned sure your critical data is safely backed up before fiddling with release version updates during the release cycle’s culmination. Specifically, I’m migrating as much as I can within limits of my own laziness in the near future from Debian to FreeBSD. Your mileage may vary.