Una limitación de almacenamiento de los primeros años de Unix terminó creando una de las peculiaridades más duraderas de los sistemas Linux: la existencia de árboles paralelos como /bin y /usr/bin, o /lib y /usr/lib. Más de cinco décadas después, Debian ha tenido que dedicar años de trabajo a eliminar las diferencias entre ambos mundos mediante el llamado merged-/usr.
Las claves de /usr en 30 segundos
- La explicación histórica más conocida sitúa el origen de
/usren la transición de Unix al PDP-11 y la separación del sistema y los archivos de usuario en distintos discos. - Cuando el sistema creció, parte de su estructura acabó replicándose bajo
/usr, dando lugar a rutas como/usr/biny/usr/lib. - Décadas después, la existencia simultánea de
/biny/usr/bincomplicó herramientas comodpkg, especialmente durante las migraciones hacia un/usrunificado. - Debian llegó a establecer una moratoria sobre determinados movimientos de archivos entre
/y/usrmientras se resolvían los problemas de actualización. - Debian 13 ha completado la transición hacia merged-/usr:
/bin,/sbiny/libpasan a ser enlaces simbólicos hacia sus equivalentes bajo/usr.
La historia tiene una ironía difícil de ignorar. El diseño original no nació de una mala planificación ni de una discusión sobre cómo debía organizarse Unix durante las siguientes décadas. La explicación que Rob Landley recuperó en 2010 relaciona la separación con una limitación mucho más prosaica: el sistema operativo había crecido hasta superar la capacidad del disco utilizado inicialmente.
Landley explicó que Ken Thompson y Dennis Ritchie llevaron Unix desde el PDP-7 al PDP-11 alrededor de 1971 y que el nuevo sistema utilizaba dos unidades de disco. Una se destinaba al sistema y la otra al espacio de los usuarios. Cuando el sistema creció demasiado, parte de sus propios directorios tuvo que pasar al segundo disco, que ya estaba asociado con /usr. De ahí surgió la estructura duplicada que todavía resulta familiar en Linux.
Hay que tratar esta historia con cierta precisión: la explicación procede de un relato posterior de Rob Landley, no de una nota de Thompson o Ritchie escrita en 1971 que documente literalmente la decisión como una planificación deliberada de /usr. La anécdota es muy conocida porque ofrece una explicación técnica coherente de la estructura, pero su detalle histórico no debería presentarse como si existiera un acta original de aquella decisión.
De un disco lleno a dos árboles de Unix
La separación tenía sentido mientras existía una diferencia física entre las partes del sistema. El problema aparece cuando esa distribución deja de tener una razón técnica pero las rutas permanecen porque demasiadas herramientas y paquetes dependen de ellas.
Así se explica la presencia histórica de /bin, /sbin y /lib junto a /usr/bin, /usr/sbin y /usr/lib. El primer grupo representaba tradicionalmente elementos necesarios en las primeras fases del arranque, mientras que /usr contenía una parte más amplia del sistema.
La evolución posterior de Linux hizo que esa separación física dejara de ser necesaria en muchos sistemas. /usr ya no tenía por qué estar situado en un disco independiente y, además, los sistemas modernos podían disponer de todo el espacio de almacenamiento como una única jerarquía.
Pero eliminar las diferencias no consiste simplemente en mover directorios.
El problema aparece cuando un programa de gestión de paquetes considera /bin/foo y /usr/bin/foo como dos rutas distintas mientras el sistema de archivos las convierte en dos nombres para el mismo lugar. En un sistema merged-/usr, por ejemplo, /bin puede ser un enlace simbólico hacia /usr/bin, de modo que ambas rutas terminan apuntando al mismo archivo. Debian documenta actualmente este comportamiento como parte de su diseño de merged-/usr.
Eso obliga a que las herramientas de empaquetado sepan trabajar con la nueva realidad.
Cuando mover un archivo podía romper una actualización
Uno de los ejemplos más claros apareció alrededor de libcrypt.so.1. En 2020, desarrolladores de Debian documentaron problemas derivados del movimiento de bibliotecas entre /lib y /usr/lib. En determinados sistemas que utilizaban un /usr unificado mediante enlaces, cambiar el paquete propietario de una ruta podía provocar que una biblioteca desapareciera durante una actualización, dependiendo del orden en que dpkg desempaquetara y retirara los paquetes.
El problema llegó a tener consecuencias prácticas. El bug #993755 documentó actualizaciones en las que /usr/bin/perl dejaba de encontrar libcrypt.so.1, provocando errores durante la configuración de libc6 y dejando dpkg en una situación en la que la propia herramienta de paquetes no podía continuar con normalidad. Debian incluyó posteriormente advertencias y procedimientos de recuperación en sus notas de publicación.
La cuestión era más profunda que una biblioteca concreta. dpkg necesitaba distinguir correctamente entre una ruta lógica del paquete y el archivo físico que acababa existiendo en el sistema.
Por eso el proyecto Debian tuvo que establecer reglas específicas durante la transición. El Comité Técnico recomendó no mover individualmente archivos desde /bin, /lib o /sbin hacia sus equivalentes en /usr durante el ciclo de Debian 12. El objetivo era evitar que diferentes paquetes y versiones realizaran movimientos independientes antes de que las herramientas de empaquetado pudieran gestionarlos de forma segura.
La llamada moratoria de movimientos de archivos terminó siendo una parte importante de la transición. No significaba que Debian hubiese abandonado merged-/usr, sino que el proyecto quería completar la infraestructura necesaria antes de permitir que los paquetes fueran cambiando sus ubicaciones por separado.
El caso de systemd que tardó casi dos años
Aquí aparece uno de los ejemplos más reveladores de cómo una decisión aparentemente pequeña puede convertirse en trabajo pendiente durante años.
En octubre de 2021, Ferenc Wágner abrió el bug #995569 de debhelper porque dh_installsystemd no detectaba correctamente las unidades de systemd instaladas bajo /usr/lib/systemd/system. Si un proyecto upstream colocaba allí sus archivos de servicio, la herramienta podía no procesarlos durante la construcción del paquete y, como consecuencia, esas unidades no quedaban habilitadas o gestionadas como correspondía al instalar el paquete.
La discusión no fue simplemente técnica.
Niels Thykier, mantenedor de debhelper, explicó que no quería implementar el cambio mientras el Comité Técnico de Debian no resolviera determinados aspectos de la transición hacia merged-/usr. Había expresado públicamente objeciones a parte del plan y consideraba que implementar unilateralmente aquella función podía interpretarse como tomar posición en una discusión que todavía estaba abierta.
En febrero de 2023, Michael Biebl volvió sobre el problema con cifras concretas: 35 paquetes de Debian unstable instalaban un total de 78 unidades en /usr/lib/systemd/system que dh_installsystemd no estaba procesando correctamente.
El problema no consistía en que systemd no entendiera /usr/lib/systemd. De hecho, systemd llevaba tiempo soportando unidades tanto en /lib/systemd como en /usr/lib/systemd. El desfase estaba en las herramientas de empaquetado de Debian.
En agosto de 2023, Helmut Grohne terminó integrando el cambio en debhelper. El commit dejó claro que la modificación no trasladaba automáticamente los archivos a /usr: simplemente hacía que las herramientas reconocieran también las unidades situadas allí.
La documentación actual de debhelper refleja ya esa evolución. Las unidades generadas por dh_installsystemd se instalan bajo usr/lib/systemd/system en el directorio de construcción del paquete.
El episodio resume bastante bien la dificultad real de la migración: no basta con cambiar un directorio. Hay que modificar el gestor de paquetes, las herramientas de construcción, los scripts de mantenimiento, los instaladores y los paquetes existentes sin romper las actualizaciones.
Debian ya ha cruzado la línea de llegada
La historia ha llegado a una fase diferente con Debian 13, Trixie.
Las notas de publicación establecen que el diseño merged-/usr es ahora obligatorio. Las antiguas /bin, /sbin, /lib y variantes como /lib64 dejan de ser directorios independientes y pasan a estar representadas mediante enlaces hacia /usr/bin, /usr/sbin, /usr/lib y /usr/lib64. Así, /bin/bash y /usr/bin/bash terminan ejecutando el mismo programa.
La propia documentación de Debian señala además que el proyecto usrmerge ha finalizado su transición y que los sistemas antiguos deben completar determinadas etapas antes de actualizar a Trixie.
Eso no significa que el viejo diseño desaparezca de la memoria del software libre. Mucho código todavía contiene rutas históricas como /bin/sh, /lib o /usr/lib, y las herramientas de construcción tienen que seguir teniendo en cuenta las diferencias entre sistemas antiguos y merged-/usr.
Para proyectos como Yocto o Buildroot, donde el sistema de archivos se construye desde componentes seleccionados y no se limita a instalar una distribución completa, esta historia resulta especialmente visible. La ubicación de una biblioteca, un ejecutable o una unidad de systemd forma parte del proceso de generación de la imagen y puede afectar a scripts, dependencias y paquetes.
Lo que comenzó como una solución a una restricción física terminó convirtiéndose en una dependencia lógica repartida por décadas de software.
En 1971, utilizar un segundo disco cuando el primero se quedaba pequeño era una solución razonable. Lo extraordinario no es que aquella decisión existiera, sino que la estructura resultante sobreviviera durante generaciones de Unix, Linux y herramientas de empaquetado.
La transición a merged-/usr demuestra precisamente cuánto código puede acumularse alrededor de una decisión de organización del sistema de archivos. El disco que obligó a crear la separación desapareció hace décadas. Las rutas, en cambio, siguieron formando parte de los contratos implícitos entre el sistema operativo, las aplicaciones y las herramientas de administración.
Preguntas frecuentes
¿Por qué existe /usr en Linux?
La explicación histórica más difundida relaciona /usr con la organización de los primeros sistemas Unix en discos separados y con el crecimiento del sistema operativo hasta superar el espacio disponible en el disco destinado inicialmente al sistema. Rob Landley documentó esta interpretación en 2010.
¿Qué significa merged-/usr?
Es una organización del sistema de archivos en la que /bin, /sbin y /lib dejan de ser árboles independientes y pasan a apuntar a sus equivalentes dentro de /usr. Debian 13 utiliza este diseño como configuración obligatoria.
¿Por qué /bin y /usr/bin podían causar problemas?
Porque las herramientas de empaquetado podían tratar inicialmente ambas rutas como ubicaciones distintas, mientras que en un sistema merged-/usr representan el mismo árbol. Durante determinadas migraciones, esa diferencia podía provocar conflictos al mover archivos entre paquetes o ubicaciones.
¿Qué ocurrió con dh_installsystemd?
Debian tuvo que adaptar dh_installsystemd para reconocer unidades de systemd instaladas bajo /usr/lib/systemd/system. El problema se reportó en 2021 y el soporte correspondiente se integró en debhelper durante 2023.
