OpenBSD's ports tree keeps GPL coreutils and rejects uutils (Rust rewrite)
OpenBSD ports 트리, GPL coreutils 유지하고 uutils 제안 거부
OpenBSD ports에 Rust로 다시 만든 uutils coreutils를 추가하려는 제안이 패키징 방식과 동작 차이 우려에 부딪혔습니다. 논의에서는 기존 GNU coreutils를 대체하거나 같은 이름으로 충돌하는 대신 선택 설치가 가능하도록 구성하는 방안이 거론됩니다.
- 주제
AI 요약
OpenBSD ports에 GNU coreutils 대안으로 uutils-coreutils를 추가하려는 제안이 메일링 리스트에서 논쟁을 불렀습니다. 제안자는 uutils가 성숙해 안정적으로 쓸 만하고 MIT 라이선스라 OpenBSD에 어울린다고 주장했습니다. 하지만 포트 관리자는 제시된 패키징 방식이 ports에서 쓰기 어렵다고 반박했습니다.
패키징 방식과 우려
제안된 패키지는 GNU coreutils와 같은 gcat, gls, gcp, gdate, gsort, gstat, gtail, gtimeout 등의 명령 이름을 설치합니다. 각 명령은 libexec/uutils에 설치되는 멀티콜 바이너리의 심볼릭 링크입니다. GNU 구현 패키지와 충돌하도록 설정하고, GNU 포트를 보조 패키지 경로로 지정하는 방식도 제시됐습니다. 포트 관리자는 이 구성이 ports에서 쓸 만한 접근인지 의문을 나타냈습니다.
메일 작성자는 Ubuntu 26.10이 uutils를 채택할 만큼 프로젝트가 성숙했다고 말했습니다. 이에 반대하는 쪽은 이미 있는 OpenBSD 유틸리티와 미묘하게 다른 동작을 하는 명령을 파이프라인에 섞으면 사용자가 예상하지 못한 문제가 생길 수 있다고 지적했습니다. 개별 유틸리티를 별도 바이너리로 설치할 수 있는지는 아직 확실하지 않다는 설명도 나왔습니다.
ports와 기본 시스템은 별개
Lobsters 댓글에서는 이번 제안이 OpenBSD 기본 시스템의 유틸리티를 교체하는 일이 아니라는 점이 짚혔습니다. ports는 기본 시스템과 분리되어 있으므로, 논점은 사용자가 선택적으로 설치할 패키지를 만들지 여부입니다. 다만 패키지 빌더에게 부담을 주는 현재 방식에는 반대가 있었고, 다른 패키징 대안도 제안됐다는 의견이 나왔습니다.
uutils의 목표가 GNU coreutils와 동작을 일치시키는 것인지도 논쟁거리였습니다. uutils 관련 댓글 작성자들은 GNU 테스트 스위트와의 차이를 버그로 보고, 드롭인 대체를 목표로 한다고 설명했습니다. 반면 다른 댓글은 현재 동작이 완전히 같지 않다면 기다렸다가 재검토하는 편이 낫다고 주장했습니다. ripgrep이나 fdfind의 설계 목표를 uutils에 그대로 적용하면 안 된다는 반론도 이어졌습니다.
Lobsters 반응
- @JulianSildenLang — coreutils를 바꾸면 많은 것이 깨질 가능성이 큽니다. 바꿀 이유가 충분히 강해야 한다고 봅니다.
- @wezm — 유틸리티가 바뀌는 것은 아닙니다. ports는 기본 시스템과 별개이고 기본 시스템은 그대로입니다. 기존 GNU coreutils 포트처럼 uutils를 선택 설치할 패키지로 제공할지를 논의한 것입니다.
- @klardotsh — “Rust를 밀어붙이려 한다”는 말과 적대적인 반응이 어디서 나왔는지 잘 모르겠습니다. OpenBSD 프로젝트에 관한 과거 맥락을 놓친 것일 수도 있습니다. 거의 호환되지만 완전히 같지는 않은 coreutils로 바꾸지 않겠다는 결정은 합리적으로 보입니다. CLI를 운영체제의 프로그래밍 언어처럼 본다면, 호환성을 깨는 변경은 충분한 예고와 공개된 이전 계획 없이 피해야 합니다. Python 2 사례에서 배울 점이 있습니다.
- @gerikson — 과거 Rust 지지자들이 OpenBSD 프로젝트를 겨냥했다가, Rust가 지원하는 플랫폼이 OpenBSD보다 훨씬 적고 ‘기본 시스템으로 기본 시스템을 빌드하는’ 부트스트랩이 주류 아키텍처 밖에서는 사실상 불가능하며, 주류 아키텍처에서도 Rust 빌드가 훨씬 오래 걸린다는 이유로 거절당한 일이 배경일 수 있습니다. 평소에도 까칠한 de Raadt에게 Rust를 밀었던 과거를 상기시키는 건 좋지 않은 접근입니다.
- @tb — 별로 복잡한 일은 아닙니다. 제안은 ports 빌더에게 부담을 준다는 이유로 강한 반대에 부딪혔습니다. uutils를 ports에서 쓸 수 있게 하는 것 자체에 반대하는 사람은 없는 듯하고, bentley@가 실행 가능한 대안을 제안했습니다. 다만 관심이 크지 않습니다. 메일링 리스트의 어조가 거칠 때가 있지만, 이번 기여자도 처음 참여한 사람은 아닙니다. 이 이야기를 정말 Lobsters에서 논의해야 할까요?
- @wezm — Theo de Raadt는 파이프라인에 동작이 미묘하게 다른 유틸리티를 넣고 싶어 하는 사람은 없다고 주장했습니다. 어떤 파이프라인을 말하는지는 잘 모르겠습니다. uutils에 차이가 있을 수는 있지만 GNU 유틸리티와 최대한 일치하는 것이 분명한 목표입니다. 새 버전마다 GNU coreutils 테스트 스위트에 얼마나 가까워졌는지 알립니다. 최종 목표는 차이가 없는 상태입니다.
- @gerikson — 지금 완전히 일치하지 않는다면 그게 바로 미묘하게 다른 동작입니다. Ubuntu에서 1~2년 실행해 본 뒤 ports에 포함할지 다시 논의하는 게 합리적입니다.
- @ploum — 최종 목표가 차이가 없는 상태라는 말은 전혀 맞지 않습니다. 기본 동작을 더 직관적으로 만들려는 여러 의견 차이가 있습니다. rg는 grep보다, fdfind는 find보다 직관적입니다. 하지만 그런 차이는 동작을 미묘하게 깨뜨리기도 합니다. 한동안 Rust 유틸리티를 좋아했지만 차이를 발견하고 오래된 GNU 유틸리티를 제대로 익히기 시작하면서, 왜 그렇게 만들어졌는지 이해하게 됐습니다. Ubuntu의 의도는 독점 제품에 포함하려고 GPL 코드를 최대한 없애는 것이라고 진심으로 믿습니다. 이 시점에 Theo de Raadt가 GPL을 옹호하는 점도 꽤 놀랍습니다.
- @sdt — 메일에서 다룬 uutils의 목표는 coreutils 동작을 일치시키는 것입니다. GNU 유틸리티의 드롭인 대체를 지향하고, GNU와의 차이는 버그로 취급합니다. rg와 fdfind는 별개의 프로젝트이며 목표도 다릅니다.
- @tauonmsdz — 최종 목표가 차이가 없는 상태라는 말은 전혀 맞지 않습니다. 더 직관적인 기본 동작을 만들려는 여러 의견 차이가 있습니다. 다만 rg와 fdfind는 uutils에 포함되지 않는다고 기억합니다. ripgrep은 적어도 드롭인 대체를 목표로 하지 않습니다. 그 점에는 동의합니다.
원문: OpenBSD ports mailing list / 번역·요약: Trawling