This question already has an answer here:

I installed a Debian stable from ISO.

/etc/debian_version was "9.5".

Then I changed apt from "stretch" to "testing" and upgraded.

Now debian_version is "buster/sid"!?

I thought sid is always "unstable" so why is there sid in the version-string?

marked as duplicate by Stephen Kitt debian Aug 25 '18 at 17:05

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


Quoting from DebianTesting, here's how are "built" all packages for testing:

Packages from Debian Unstable enter the next-stable testing distribution automatically, when a list of requirements is fulfilled:

  • The package has been in "unstable" at least for 2-10 days (depending on the urgency of the upload).
  • The package has been built for all the architectures which the present version in testing was built for.
  • Installing the package into testing will not make the distribution more uninstallable.
  • The package does not introduce new release critical bugs.

So no package from testing has been built for the testing distribution. They were all initially built for the unstable distribution. In these conditions there is no way to distinguish if a package is an unstable package or a testing package by its content only. So the package base-files providing /etc/debian_version has been built as unstable (permanent codename: sid) at a time when the testing distribution was named (or intended to be named) with the codename buster. It was then migrated to testing once the conditions above applied (which shouldn't be difficult for this package).

  • This doesn’t detract from you main points, and is really a point of detail; but in some (rare) cases, packages do end up being built directly for testing, e.g. to fix security issues which need an urgent fix which can’t wait for the usual migration from unstable (either because the issue is very severe, or because the migration is more complex than usual). – Stephen Kitt Aug 25 '18 at 17:13
  • I agree it's possible, but that's the usual role of the urgency of the upload described in the first step of the migration. urgency=critical will select 2 days only for the migration. Users of the testing distribution should know they are the last served for security fixes: either stable gets it first from direct backported patch, or unstable gets it first from a new upstream version, then testing will get it – A.B Aug 25 '18 at 17:17
  • hum except urgency=critical appears to be faster than that. 2 days is probably for urgency=high (eg: tracker.debian.org/pkg/blueman for 2.0.4-1 ) – A.B Aug 25 '18 at 17:30
  • I agree that’s what urgency is for, but urgency is a source-package-local flag only, and it only has the effect of shortening the wait time if all the dependencies are also in testing; that’s the issue that can cause (huge) delays in propagation. And yes, testing users need to be aware that they get security fixes last. – Stephen Kitt Aug 30 '18 at 9:01

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