A storage limitation from Unix’s earliest years helped create one of the longest-lasting quirks in Linux systems: parallel directory trees such as /bin and /usr/bin, or /lib and /usr/lib. More than five decades later, Debian has spent years removing the differences between these two worlds through the so-called merged-/usr transition.

Key facts about /usr in 30 seconds

The best-known historical explanation traces /usr back to the transition of Unix to the PDP-11 and the separation of the operating system and user files across different disks.
As the system grew, parts of its own directory structure ended up under /usr, creating paths such as /usr/bin and /usr/lib.
Decades later, having both /bin and /usr/bin complicated tools such as dpkg, particularly during the transition toward a unified /usr.
Debian eventually introduced a moratorium on certain file moves between / and /usr while the problems were being resolved.
Debian 13 completed the transition to merged-/usr: /bin, /sbin, and /lib now become symbolic links to their counterparts under /usr.

The story has an irony that is hard to miss. The original design did not emerge from poor planning or from a debate about how Unix should be organized for the next several decades. The explanation that Rob Landley documented in 2010 links the split to a much more mundane limitation: the operating system had grown beyond the capacity of the disk initially being used.

Landley explained that Ken Thompson and Dennis Ritchie moved Unix from the PDP-7 to the PDP-11 around 1971 and that the new system used two disk drives. One was used for the system and the other for users’ files. As the system grew too large, some of its own directories had to move onto the second disk, which was already associated with /usr. This is how the duplicated structure that remains familiar on Linux today emerged.

There is an important historical qualification here: this explanation comes from a later account by Rob Landley, rather than from a 1971 document written by Thompson or Ritchie that literally records the decision as a deliberate plan for /usr. The story is widely cited because it provides a technically coherent explanation of the directory structure, but its historical details should not be presented as though an original record of the decision exists.

From a Full Disk to Two Unix Trees

The separation made sense while there was a physical distinction between different parts of the system. The problem appeared when that physical reason disappeared but the paths remained because too many tools and packages depended on them.

This is how Linux ended up with the historical separation between /bin, /sbin, and /lib on one side and /usr/bin, /usr/sbin, and /usr/lib on the other. Traditionally, the first group represented components needed during the early stages of boot, while /usr contained a broader part of the system.

Linux later evolved to the point where that physical separation was no longer necessary on many systems. /usr did not need to live on a separate disk, and modern systems could also use their storage as a single hierarchy.

But removing the distinction is not simply a matter of moving directories.

The problem appears when a package manager considers /bin/foo and /usr/bin/foo to be two different paths while the filesystem turns them into two names for the same location. On a merged-/usr system, for example, /bin can be a symbolic link to /usr/bin, meaning both paths ultimately refer to the same file. Debian currently documents this behavior as part of its merged-/usr design.

That requires packaging tools to understand the new reality.

When Moving a File Could Break an Upgrade

One of the clearest examples appeared around libcrypt.so.1. In 2020, Debian developers documented problems caused by moving libraries between /lib and /usr/lib. On systems using a /usr hierarchy implemented through symbolic links, changing which package owned a particular path could cause a library to disappear during an upgrade, depending on the order in which dpkg unpacked and removed packages.

The issue had practical consequences. Debian bug #993755 documented upgrades in which /usr/bin/perl could no longer find libcrypt.so.1, causing errors while configuring libc6 and leaving dpkg in a state where the package manager itself could not continue normally.

The underlying problem was deeper than one particular library. dpkg had to correctly distinguish between a package’s logical path and the physical file that ultimately existed on the system.

That is why the Debian project had to establish specific rules during the transition. The Technical Committee recommended avoiding individual file moves from /bin, /lib, or /sbin to their /usr counterparts during the Debian 12 cycle. The goal was to prevent different packages and versions from making independent moves before the packaging tools could handle them safely.

The resulting file-move moratorium became an important part of the transition. It did not mean that Debian had abandoned merged-/usr. Instead, the project wanted to complete the necessary infrastructure before allowing packages to change their locations independently.

The systemd Case That Took Almost Two Years

One of the clearest examples of how a seemingly small issue can turn into years of maintenance work appeared around debhelper.

In October 2021, Ferenc Wágner opened Debian bug #995569 because dh_installsystemd did not correctly detect systemd units installed under /usr/lib/systemd/system. If an upstream project placed its service files there, the Debian helper could fail to process them during package construction, meaning those units were not handled as expected when the package was installed.

The discussion was not purely technical.

Niels Thykier, the debhelper maintainer, explained that he did not want to implement the change while Debian’s Technical Committee was still considering aspects of the merged-/usr transition. He had publicly expressed objections to parts of the plan and considered that implementing the function unilaterally could be interpreted as taking a position in a discussion that was still open.

In February 2023, Michael Biebl returned to the issue with concrete figures: 35 Debian unstable packages were installing a total of 78 units under /usr/lib/systemd/system that dh_installsystemd was not correctly processing.

The problem was not that systemd itself failed to understand /usr/lib/systemd. Systemd had supported units in both /lib/systemd and /usr/lib/systemd for some time. The mismatch was in Debian’s packaging tools.

In August 2023, Helmut Grohne eventually integrated the change into debhelper. The change did not move the files to /usr; it simply taught the tooling to recognize units located there as well.

Current debhelper documentation reflects that evolution. Units handled by dh_installsystemd are now installed under usr/lib/systemd/system in the package build directory.

The episode captures the real difficulty of the migration: changing a directory is not enough. The package manager, build tools, maintainer scripts, installers, and existing packages all have to be updated without breaking upgrades.

Debian Has Now Crossed the Finish Line

The story has reached a different stage with Debian 13, Trixie.

The release notes state that the merged-/usr layout is now mandatory. The former /bin, /sbin, /lib, and related paths such as /lib64 are no longer independent directory trees and instead point through symbolic links to /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64. As a result, /bin/bash and /usr/bin/bash ultimately execute the same program.

Debian’s documentation also states that the usrmerge project has completed its transition and that older systems need to complete specific migration steps before upgrading to Trixie.

That does not mean the old design has disappeared from free software. A large amount of code still contains historical paths such as /bin/sh, /lib, or /usr/lib, and build tools still have to account for differences between older systems and merged-/usr systems.

For projects such as Yocto or Buildroot, where the filesystem is assembled from selected components rather than simply installing a complete distribution, this history is especially visible. The location of a library, executable, or systemd unit is part of the image-generation process and can affect scripts, dependencies, and packages.

What began as a solution to a physical storage limitation eventually became a logical dependency spread across decades of software.

In 1971, using a second disk when the first one ran out of space was a reasonable solution. What is remarkable is not that the decision existed, but that the resulting structure survived through generations of Unix, Linux, and packaging tools.

The move to merged-/usr shows just how much code can accumulate around a filesystem organization decision. The disk that forced the split disappeared decades ago. The paths, however, continued to form part of the implicit contracts between the operating system, applications, and system administration tools.

Frequently Asked Questions

Why does Linux have `/usr`?

The most widely cited historical explanation links /usr to the organization of early Unix systems across separate disks and to the operating system growing beyond the space available on the disk initially assigned to the system. Rob Landley documented this interpretation in 2010.

What does merged-/usr mean?

It is a filesystem layout in which /bin, /sbin, and /lib cease to be independent directory trees and instead point to their counterparts inside /usr. Debian 13 uses this layout as a mandatory configuration.

Why could `/bin` and `/usr/bin` cause problems?

Because packaging tools could initially treat the two paths as separate locations, while on a merged-/usr system they represent the same directory tree. During certain migrations, this could cause conflicts when files were moved between packages or locations.

What happened with `dh_installsystemd`?

Debian had to adapt dh_installsystemd to recognize systemd units installed under /usr/lib/systemd/system. The issue was reported in 2021 and the corresponding support was integrated into debhelper in 2023.