Control: tags -1 +wontfix Hi there Luca,
Le dimanche, 8 janvier 2017, 14.54:16 h CET Luca Boccassi a écrit : > Any chance this could be looked at before Stretch final freeze? Thank you! tl;dr: unfortunately not. I have thought about this issue for some time, and I think that the result is actually correct. Let me explain: When (as currently), stretch is the testing release, /etc/debian_version contains "stretch/sid", as shipped by base-files. It is therefore impossible to rely on that file to differentiate between a host running testing or unstable without asking apt what is actually preferred when installing packages (through parsing `apt-cache policy`). That's how `lsb-release -- codename` returns "sid" _xor_ "stretch". stretch's base-files is currently in version 9.7, and ships with "stretch/sid" in /etc/debian_version. But if you look at base-files in the current stable (8+deb8u6), its /etc/debian_version currently contains "8.6", and with that, `lsb-release --codename` returns "jessie" consistently, and without relying on apt. base-files will be updated in stretch for the release, as happened for jessie: > * Release for jessie as stable: > - Use "8" as version in /etc/issue and /etc/issue.net. As usual, this > is never expected to change once that jessie is released as Debian 8. > - Use 8.0 as version in /etc/debian_version. As usual, this is expected > to change at every point release. So, if you manually replace your /etc/debian_version's content by "9.0", you should get "stretch" consistently, no matter what your apt configuration is. That's all to say that this bug is (to my belief) actually expected behaviour; and fixing it through forcing the codename to be interpreted as "stretch" when apt-cache information is unavailable would be wrong. When /etc/debian_version contains "potato/sid", the codename is either potato xor sid, and only apt- cache can discriminate a testing host from a sid host. Therefore, in such a situation, the correct answer is actually "I can't tell", aka "n/a". -- Cheers, OdyX