Contexte de la proposition
Le 20 septembre 2026, David Uhden Collado a soumis le port sysutils/uutils à l’arbre des ports d’OpenBSD. Ce port propose de remplacer les implémentations GNU des utilitaires de base par les ré‑implémentations Rust du projet uutils coreutils, distribuées sous forme d’un seul binaire multicall placé dans libexec/uutils. Chaque utilitaire est exposé via un lien symbolique préfixé g (par ex. gcat, gls, gcp), qui pointe vers le même exécutable. Le paquet entre en conflit avec le port GNU correspondant et indique ce dernier comme dépendance secondaire via @pkgpath.
Cette soumission a immédiatement suscité une opposition virulente de la part des développeurs seniors d’OpenBSD, dont Stuart Henderson et le fondateur Theo de Raadt, qui ont qualifié l’initiative d’« agenda » et d’inutile duplication.
Analyse des enjeux de compatibilité et de comportement
OpenBSD distribue depuis des décennies des utilitaires BSD‑licenciés dont le comportement est soigneusement harmonisé. Les développeurs soulignent que même des différences subtiles dans le format de sortie, les codes de retour ou la gestion d’erreurs peuvent casser des pipelines scriptés. Par exemple, remplacer ls par gls pourrait générer une sortie légèrement différente, entraînant l’échec d’un sed ou d’un cut qui attend une forme précise. Cette sensibilité est au cœur du rejet : l’introduction d’une seconde suite d’utilitaires, même compatible au niveau fonctionnel, crée un risque de « behavioural incompatibility » qui va à l’encontre du principe d’un système de base cohérent.
Le port uutils utilise un modèle multicall inspiré de BusyBox, où un seul binaire décide de l’utilitaire à exécuter en fonction du nom invoqué (argv[0]). Cette architecture contredit les conventions d’OpenBSD qui privilégient des binaires distincts, facilitant la mise à jour granulaire et la traçabilité des changements. Un correctif d’un seul utilitaire impliquerait la recompilation et la redistribution de l’ensemble du paquet, augmentant la charge de maintenance.
Problèmes liés à l’adoption de Rust et à la chaîne d’outils
Le choix du langage Rust a été un autre point de friction. OpenBSD maintient son propre compilateur C et évite d’ajouter des runtimes externes à la base du système. Rust, avec son cycle de versions rapides et ses dépendances lourdes, compliquerait le processus de bootstrapping sur les architectures supportées par OpenBSD (amd64, arm64, etc.). De Raadt a rappelé que la communauté OpenBSD privilégie la stabilité ; l’intégration d’un nouveau toolchain pourrait introduire des vulnérabilités ou des incompatibilités non anticipées.
De plus, la comparaison avec Ubuntu 26.10, qui n’était pas encore publié au moment de la discussion, a été jugée hors de propos. Le calendrier de publication d’OpenBSD (7.6 en octobre 2024, 7.7 prévu pour avril 2025) suit un rythme conservateur, rendant difficile l’alignement avec les évolutions rapides de l’écosystème Rust.
Perspectives et alternatives
Le port reste à l’état de proposition. Sans modifications majeures – découpage du binaire multicall en exécutables séparés, démonstration d’une parité stricte avec les utilitaires de base, et résolution du problème de bootstrapping Rust – il est improbable qu’il soit accepté. Les utilisateurs d’OpenBSD qui souhaitent des utilitaires GNU continuent d’utiliser le port sysutils/coreutils, qui fournit les implémentations GNU classiques. Le rejet du port uutils illustre la divergence philosophique entre les distributions Linux, où les utilitaires sont souvent interchangeables, et OpenBSD, qui considère chaque composant comme partie intégrante d’un système cohérent et testé en profondeur.
