Linux 배포판에서 버그 수정이 정확히 어떻게 작동하는지 알고 싶습니다. 내 말은, 결국 배포판은 외부 개발자가 만든 오픈 소스 소프트웨어로 구성되고 배포판 관리자가 패키징한다는 뜻입니다. 그렇다면 각 배포판에는 왜 자체 버그 추적기가 있습니까? 이러한 버그는 해당 소프트웨어의 원저작자에게 보고되어야 하지 않습니까?
답변1
(나는 원저작자 또는 원소프트웨어를 업스트림 저작자 및 업스트림 소프트웨어라고 부르는데, 그 이유는 그것이 내가 그들을 부르는 데 익숙하기 때문입니다.)
최종 사용자의 관점에서 볼 때, 사용하는 모든 소프트웨어에 대해 다양한 업스트림 버그 추적기에 계정을 등록하지 않고도 버그를 보고할 수 있는 장소가 있다면 좋을 것입니다.
업스트림 작성자의 관점에서 보면 다음과 같은 이유로 배포 사용자의 버그 보고서에 영향을 받지 않는 것이 좋습니다.
- 배포판 관리자는 버그 자체를 도입할 수 있으므로(또는 배포판 패키지 간의 상호 작용으로 인해 버그가 발생할 수 있음) 이를 수정하는 것이 업스트림 작성자의 몫이 되어서는 안 됩니다.
- 배포판에는 업스트림 소프트웨어 작성자가 신경 쓰지 않거나 처리할 수 없는 요구 사항이 있을 수 있습니다(예를 들어다양한 하드웨어 아키텍처).
이는 업스트림 소프트웨어의 버그가 전달되지 않는다는 의미는 아닙니다. 업스트림 소프트웨어의 버그가 전달되지 않는다는 의미입니다. 사용자가 릴리스 버그 추적기에 버그를 신고하고 해당 버그가 업스트림의 책임인 경우 해당 버그는 업스트림 버그 추적기로 전달됩니다. 그러나 일반적으로 배포 관리자가 이 문제를 처리합니다. 복잡한 버그의 경우 사용자는 중개자를 피하기 위해 업스트림을 따르도록 안내될 가능성이 높습니다. 릴리스 버그 추적기는 이를 잘 지원하며 업스트림 버그 추적기에서 버그가 변경되면 자동으로 버그 상태를 업데이트합니다.
배포판 관리자의 관점에서 배포판 자체가 달성하려는 작업(라이브러리 버전 변경, 새 도구 모음, 새 아키텍처, 새 배포 도구...)을 추적하려면 배포판별 버그 추적기가 필요합니다.
또한 많은 경우 배포판은 이전 버전의 패키지에 대한 지원을 제공하며 업스트림 작성자가 최신 버전의 소프트웨어에서 이러한 버그를 수정했지만 이러한 버그는 여전히 존재할 수 있습니다. 이 경우 사용자가 업스트림 작성자에게 버그 수정을 요청하는 것은 약간 짜증나는 일입니다. 왜냐하면 업스트림 관점에서 볼 때 버그가 이미 수정되었기 때문입니다. 버그가 충분히 짜증나는 경우 배포판 관리자가 수정 사항을 백포트해야 합니다. (중요 패키지의 보안 수정 사항에 대해서는 논란의 여지가 있습니다. 많은 업스트림에서는 이전 버전 자체에 대한 보안 수정 사항을 제공합니다.)
고려해야 할 또 다른 요소는 여전히 중요한 일부 소프트웨어가 더 이상 업스트림을 갖지 않을 수 있다는 것입니다. cron예를 들어, 이러한 상황은 오랫동안 지속될 수 있습니다. 배포판에 자체 버그 추적기가 없으면 사용자는 해당 소프트웨어의 버그를 보고할 수 없습니다.
대부분의 프로젝트에서 이 모든 것은 친근한 방식으로 매우 자연스럽게 발생하는 경향이 있습니다. 배포판 관리자는 업스트림 수정 버그를 돕고, 그 반대의 경우 배포판 관리자는 버그 수정을 다른 배포판과 공유합니다.