Linux 배포판에 대한 제가 이해한 바에 따르면 업데이트에 대한 알림을 받은 다음 간단한 클릭이나 여러 명령을 사용하여 업데이트를 설치합니다. 이는 이전에 설치한 소프트웨어에 대한 패치 또는 부 버전 업데이트일 수 있습니다. 예를 들어, 배포판에서는 Firefox 버전 23을 Firefox 버전 24로 업그레이드하도록 권장할 수 있습니다(나쁜 예, 부 버전은 아니지만 아이디어를 얻을 수 있음). 그러나 몇 달 후에 업그레이드하라는 메시지가 표시됩니다. 설치한 패키지가 아니라 시스템 자체를 업데이트하는 것입니다.
다른 소프트웨어 패키지처럼 소규모의 지속적인 업데이트를 통해 시스템 자체를 업데이트할 수 없는 이유는 무엇입니까?
이 문제를 해결하기 위해 롤링 릴리스에는 어떤 솔루션이 사용됩니까?
답변1
다른 소프트웨어 패키지처럼 소규모의 지속적인 업데이트를 통해 시스템 자체를 업데이트할 수 없는 이유는 무엇입니까?
아시다시피 일부 배포판은 이런 방식으로 작동합니다. 업그레이드 프로세스는 본질적으로 일련의 업데이트입니다. "시스템 자체 업데이트"와 "설치한 패키지가 아님" 간의 구별은 약간 부정확합니다.예방금 설치한 패키지입니다. 다양한 배포가능한업그레이드에만 적용되는 몇 가지 명확한 기준이 있지만 이것이 이 접근 방식을 사용하는 이유는 아니라고 생각합니다. 버전 업그레이드를 사용하는 데 특별한 기술적 이유가 전혀 없다고 생각하며, 기존 버전 제어 릴리스를 롤링 릴리스로 변환하는 데 너무 많은 시간이 걸릴 것이라고 생각합니다.
가장 큰 이유는 구획화라고 생각합니다. 버전 2에서는 일련의 되돌릴 수 있는 조정만으로는 달성할 수 없는 버전 1에 대한 중요한 변경이 필요할 수 있습니다. 따라서 버전 2를 개발하는 동안 버전 2에서 작동하지 않는 버전 1을 계속 유지해야 할 수도 있습니다. 거의모두이것이 실제 소프트웨어가 수행되는 방식입니다. AFAIK, 그건 단지 소프트웨어일 뿐이야분산롤링 릴리스 모델을 사용합니다.
더욱이, 처음에 V.2가 심각한 실패로 판명되면 사용자는 이전 버전을 사용하는 것을 선호할 것입니다. 이는 확실히 Linux 배포판에 적용되는 논리입니다.
이 문제를 해결하기 위해 롤링 릴리스에는 어떤 솔루션이 사용됩니까?
글쎄요, 그들은 패키지에 버전 제어를 사용합니다. 위에서 언급했듯이 시스템이 좋기 때문에 좋습니다.오직가방. 설치된 모든 것은 패키지의 일부이므로 시스템 수정은 단지 몇 개의 패키지를 전체적으로 변경하는 문제일 뿐입니다.
버전이 지정된 릴리스를 사용하면 패키지에는 실제로 패키지 버전과 릴리스 버전이라는 두 가지 버전이 연결됩니다. 예를 들어, whatever.1.2.3해당 배포에 대한 패키지의 여러 동시 버전을 찾을 수 있습니다 . 나는 이것이 릴리스 간의 "획기적인 변경"이라고 부르는 것에 상당한 유연성을 제공한다고 생각합니다. 뭐든지 1.2.3은 동일한 업스트림(원본) 소스에서 나올 수 있지만 릴리스 1과 관련된 중요한 아키텍처 변경 사항을 반영하기 위해 릴리스 2에서는 다르게 구성될 수 있습니다.