패키지는 두 가지 주요 버전의 패키지 간 전환을 용이하게 할 필요가 있거나 그렇게하는 데 시간이 오래 걸리는 것처럼 이름이 지정됩니다. 전환 기간 동안 새 버전과 이전 버전을 모두 사용할 수 있으며 향후에는 이전 버전이 중단 될 것이라는 점을 이해하고 있습니다.
현재 사용중인 시스템 릴리스 중에 전환 기간이 발생하는 경우가 있습니다. 일부 패키지의 경우 모든 새 시스템 릴리스 에서 전이 패키지 버전을 볼 수있을 정도로 자주 발생합니다 . 시스템 릴리스와 동일한 일정으로 새 도구로 업그레이드하는 것은 실용적이지 않을 수 있으므로 소프트웨어 개발 도구는 종종이 범주에 속합니다. GCC, Autoconf 및 Perl의 특정 버전에 대한 회사의 의존도는 5 년주기이고 OS는 3 년 업그레이드주기 일 수 있습니다. 따라서 새 OS를 개발할 당시의 최신 버전 외에 일부 패키지의 이전 버전이 포함되어 있으면 새 OS를 쉽게 채택 할 수 있습니다.
다른 경우, 이러한 주요 버전 변경 사항은 오래 전에 오래 전에 발생했으며 이제는 모든 사람이 현재 버전을 사용하고 있습니다. 예를 들어 Apache의 경우입니다. 1.3에서 2.0으로의 변경은 모든 2.x 버전 변경보다 호환성 관점에서 훨씬 더 큰 거래 였으므로 모든 사람이 1.3을 벗어나면 더 이상 특정 OS 릴리스 내에서 여러 Apache 버전을 계속 제공 할 필요가 없었습니다. 그러나 모든 사용자가 apache2
패키지를 사용하게되면 다시 이름을 바꾸는 데 대한 좋은 주장은 없습니다 apache
. 불필요한 업그레이드 번거 로움이 생길 수 있습니다. 게다가, 과거에 두 개의 병렬 버전을 일시적으로 제공해야한다는 인식이 있었지만, 앞으로도 그 필요성이 다시 발생할 것입니다.
이 패키지 명명 실습은 일반적으로 라이브러리 또는 중요한 핵심 패키지에서만 발생합니다. 더 많은 주변 장치 패키지의 경우 현재의 현재 상태로 업그레이드하면됩니다.
라이브러리는 특성상 다른 패키지가 라이브러리에 의존하기 때문에 애플리케이션보다 이러한 방식으로 더 일반적으로 처리됩니다. 라이브러리가 대중적 일수록,이 전환 기간없이 라이브러리를 새로운 메이저 버전으로 단계적으로 업그레이드 할 수 있도록 라이브러리에 의존하는 다른 모든 패키지를 순수하게 재구성하고 다시 링크하도록 요구하는 것이 더 실용적이지 않습니다.
응용 프로그램이 이러한 방식으로 처리되는 경우 종종 응용 프로그램에 라이브러리 요소가 포함되어 있기 때문입니다. 예를 들어 Apache는 웹 서버 일뿐만 아니라 플러그인을위한 개발 API도 제공합니다. ( mod_foo
등.) 누군가가 오래된 경우 mod_something
사용자의 OS는 모든 플러그인 제작자는 기회가 될 때까지 기존의 아파치 1.3을 제공하기 위해 계속되면 ABI 플러그인 아파치 1.3에 링크를하고 새로운 2.0 API를 사용하도록 업그레이드하지 않은, 그것은 편리 플러그인을 업데이트합니다.