
OpenBSD не прийняв порт uutils на Rust, GNU coreutils залишається в дереві
У списку розсилки OpenBSD ports не прийняли пропозицію додати написаний на Rust uutils як заміну GNU-інструментів. Theo de Raadt назвав будь-яку спробу заміни цілковитим глухим кутом.
20 вересня 2026 року список розсилки OpenBSD ports не прийняв пропозицію додати написаний на Rust uutils як заміну GNU-інструментів. Засновник проєкту Theo de Raadt назвав будь-яку заміну порту GPL coreutils цілковитим глухим кутом.
Що запропонували
David Uhden Collado подав sysutils/uutils як мультипакетний порт: метапакет встановлює uutils-coreutils, uutils-findutils, uutils-diffutils, uutils-grep, uutils-awk, uutils-sed і uutils-tar, а частина coreutils базується на uutils/coreutils 0.12.0. Мета полягала в тому, щоб ці реалізації стали альтернативою GNU-портам без зміни коду залежних портів: uutils-coreutils встановлює команди з тим самим префіксом g, що й sysutils/coreutils, як символічні посилання на multicall-бінарник, а кожен пакет конфліктує з відповідною GNU-реалізацією та оголошує GNU-порт вторинним @pkgpath.
Автор визнав, що сумісність не повна: uutils-diffutils не має diff3 і sdiff, а uutils-awk переважно є POSIX-реалізацією.
Як відповіли
Stuart Henderson написав, що не вважає цей підхід придатним для ports. Автор відповів, що йому цікаві переписування на Rust, що Ubuntu 26.10 уже запровадила uutils coreutils, оскільки проєкт досяг прийнятної зрілості, і що їхня дозвільна ліцензія MIT добре підходить OpenBSD.
Реакцією Theo de Raadt була одна фраза: «Smells like agenda.» На його думку, користувачам не потрібен другий набір дозвільно ліцензованих інструментів, який поводиться лише трохи інакше за наявний: якщо конвеєр використовує OpenBSD-івський ls разом з OpenBSD-івським sed або cut і випадково покладається на нестандартний вивід, заміна того ls іншим ls призведе до зіткнення поведінки нестандартних інструментів. Щодо згадки Rust він додав: «Oh, because it is written in Rust. Your agenda is showing.»
Чому GNU coreutils залишається
de Raadt далі пояснив позицію проєкту: coreutils переважно підтримує чутливі до поведінки GNU середовища збірки та полегшує збірку складних портів; мета не в тому, щоб він був зручним для щоденної роботи, де стандартними шляхами мають користуватися власні інструменти OpenBSD. Оскільки середовище збірки залежить від максимальної стабільності повільно змінюваного coreutils, будь-яка зміна поведінки відбиратиме час у розробників ports.
Stuart Henderson сказав, що не бачить проблеми, якщо інструменти будуть у ports для охочих і буде підтримка розробників для внесення їх у дерево, але поставив дві умови: вони не повинні конфліктувати з GNU-інструментами, тому їм потрібен інший префікс або каталог, і їх не можна використовувати як залежність інших портів замість GNU-інструментів, оскільки Rust надто обмежує архітектури.
У результаті поточна ситуація незмінна: порти, які потребують поведінки GNU, і далі залежать від GNU coreutils під ліцензією GPL, а порт uutils не прийнято в дерево.
SiTech — веброзробка з підтримкою AI
Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.