On Friday, July twenty fourth, Ubuntu developer Benjamin Drung posted to the ubuntu-devel list asking whether anyone objected to removing /etc/debian_version from the base-files package. The target is Ubuntu 26.10, and the Launchpad bug he wants to close was filed in 2005. The file has never told the truth on Ubuntu: it reports the Debian Sid version the packages were derived from, not anything about the system you are actually running. Almost nobody reads it deliberately any more, which is precisely why this is worth checking, because the places that still do are old scripts, vendor installers and container base images nobody has opened in years. We looked at what breaks, and what to grep for.
The short answer
Ubuntu developer Benjamin Drung asked the ubuntu-devel list on July twenty fourth whether anyone objects to removing /etc/debian_version from the base-files package, targeting Ubuntu 26.10. The file reports the Debian Sid version the packages came from rather than anything about the running system, which is what Launchpad bug 19353 has said since 2005. The replacement is /etc/os-release, standard for about a decade. Anything still reading the old file should be moved before an upgrade makes the question urgent.
There is a particular kind of file that survives for decades because removing it feels riskier than leaving it, even though everyone agrees it is wrong. Ubuntu has been carrying one of those since its first release, and somebody has finally proposed doing something about it.
The proposal
Benjamin Drung, who works on both Debian and Ubuntu, posted to ubuntu-devel just after midnight UTC on Friday, July twenty fourth. The subject line was direct: removing /etc/debian_version from base-files. The message is a request for objections rather than an announcement of a decision, which is how changes of this shape are supposed to move.
His argument is short. Applications that still read the file should read /etc/os-release instead, which has been the de facto standard for the last ten years. The version he named as the target is Ubuntu 26.10, and the bug he wants to close is Launchpad 19353, filed in 2005 and open ever since.
Phoronix picked it up later the same day, which is how most people outside the list heard about it.
Why the file has always been wrong on Ubuntu
On Debian, /etc/debian_version does what its name says. It contains the Debian release, and reading it tells you something true.
Ubuntu inherits the file from base-files, the package that supplies the basic filesystem layout, and there the meaning falls apart. What it contains is the Debian Sid version that Ubuntu's package set was imported from during the development cycle. It is a fact about the ancestry of the archive, not about the machine. An Ubuntu system reporting a Debian testing version number is not lying exactly, but it is answering a question nobody asked.
The 2005 bug report made this point when Ubuntu was one year old. The recommendation attached to it, repeated consistently for twenty years, has been to use lsb_release or /etc/os-release instead. Both existed, both were correct, and the file stayed anyway, because the cost of removing something is paid immediately and the cost of keeping it is paid by whoever gets confused next.
What to read instead
/etc/os-release is a key value file in shell syntax, which means you can source it directly rather than parsing it, and it has been standard across distributions for long enough that assuming its presence is safe.
The fields that matter for detection logic are ID, which gives you ubuntu or debian as a machine readable identifier, VERSION_ID, which gives you 26.04 or equivalent, VERSION_CODENAME, and PRETTY_NAME for anything you are going to show a human.
ID_LIKE is the field worth knowing about if your scripts have historically used the presence of /etc/debian_version as a family check. On Ubuntu it contains debian, which is exactly the signal the old test was reaching for. Checking ID_LIKE for debian covers Ubuntu, Mint, Pop and every other derivative in the family without maintaining a list of names, and it does so through a documented interface rather than a file whose meaning was always incidental.
There is one habit worth breaking while you are in there. Sourcing os-release inside a script that then uses $NAME or $VERSION for its own purposes will collide, because those are common variable names and the file will overwrite whatever you had. Source it in a subshell, or read the fields you need without pulling the whole file into your namespace.
What is likely to break, and how to find it
Actively maintained code is not the problem here. Anything written or reviewed in the last decade already uses os-release, because that is what the documentation has said to use for the whole period.
The exposure sits in the code nobody has opened. Fleet inventory scripts written before os-release existed and never revisited because they still work. Vendor installers that shell out to a platform detection routine, particularly proprietary agents where you cannot see the logic. Container base images with a distribution check near the top of an entrypoint. Monitoring and configuration management modules doing OS fingerprinting, where the check is buried in a library rather than in your own code.
The failure mode is what makes this worth a few minutes rather than a shrug. A script doing test -f /etc/debian_version to decide whether it is on a Debian family system does not fail loudly when the file disappears. It takes the other branch, silently, and does whatever it does for a system it thinks is neither Debian nor Ubuntu. Depending on the script, that is a wrong package manager, a skipped configuration step, or an inventory entry that quietly reads unknown.
Grepping is the whole remediation plan. Search your configuration management repository, your Dockerfiles and Containerfiles, and any directory of local scripts for debian_version. On live hosts you can also confirm empirically whether anything still reads the file, which turns a guess into an answer.
The timing is fine
Nothing needs doing today. This is a proposal on a mailing list, 26.10 is an interim release rather than an LTS, and an interim release is exactly where a change like this belongs so that the sharp edges are found by people who signed up to find them. Anyone on an LTS has considerably longer.
The reason to look now anyway is that the diagnosis is easy while the file still exists and gets harder afterwards. Right now you can grep, find three scripts, and fix them in an afternoon with the old behaviour still available for comparison. After an upgrade, the same three scripts present as a misdetection somewhere downstream, and you get to work backwards from the symptom. Twenty years is a long time for a file to be wrong. It costs very little to spend twenty minutes making sure nothing of yours was depending on it.
Sources and further reading
- Benjamin Drung's post to ubuntu-devel: removing /etc/debian_version from base-files
- Phoronix: Ubuntu looking to get rid of the /etc/debian_version historical artifact
- UbuntuHandbook: Ubuntu to fix a twenty year old bug by removing /etc/debian_version
- The os-release specification
Frequently asked questions
What is /etc/debian_version and why is it wrong on Ubuntu?
It is a one line file that Debian ships to record the Debian release the system is running. Ubuntu inherits it from the base-files package, but on an Ubuntu system it does not describe Ubuntu at all: it names the Debian Sid version that the package set was derived from at some point in the release cycle. So a script that reads it on Ubuntu learns something true about a Debian snapshot and nothing true about the machine in front of it. That mismatch is the whole substance of the 2005 bug report.
What should scripts read instead?
/etc/os-release, which has been the cross distribution standard for roughly a decade and is what every modern tool already uses. It is a shell compatible key value file, so you can source it directly and read ID, VERSION_ID, VERSION_CODENAME and PRETTY_NAME. ID_LIKE is the field that matters for portable logic, because on Ubuntu it contains debian, which lets you write one branch that covers the whole family instead of maintaining a list of derivative names.
Is this decided, or still a proposal?
Still a proposal at the time of writing. Drung's post is framed as a request for objections rather than an announcement, which is the normal way a change like this moves through ubuntu-devel. Ubuntu 26.10 is the version he named as the target. Treat it as a strong signal about direction rather than a scheduled event, and note that an interim release is the right place to try something like this precisely because it is not an LTS.
What is actually going to break?
Nothing you maintain actively, most likely. The risk sits in code nobody has looked at recently: fleet inventory scripts written before os-release existed, vendor installers that shell out to detect a platform, CI images with a distribution check near the top, and monitoring agents doing OS fingerprinting. The failure mode is usually a silent misdetection rather than a crash, because a script that does test -f /etc/debian_version to decide it is on a Debian family system will simply take the wrong branch.
How do I find the code that reads it?
Grep your configuration management, container definitions and any local script directories for debian_version. On a running host, checking whether anything still opens the file gives you a live answer rather than a guess. The point of doing it now, while the file still exists, is that a wrong answer today produces a clear result you can fix, whereas the same wrong answer after an upgrade produces a misdetection you have to debug from its symptoms.
Does Debian itself keep the file?
This proposal is about Ubuntu's base-files package, so it does not remove anything from Debian. But the reasoning applies everywhere the file is read, and the migration target is the same on both. Writing your detection against os-release is the portable answer regardless of which distribution the script lands on, which is what makes this worth doing once rather than distribution by distribution.