Пакеты называются так, когда есть (или было) необходимость облегчить переход между двумя основными версиями пакета, а время, необходимое для этого, ожидается долгим. В течение переходного периода доступны как новые, так и старые версии, при том понимании, что в будущем более старые версии будут прекращены.
Иногда переходный период происходит во время выпуска системы, которую вы сейчас используете. Для некоторых пакетов такое случается достаточно часто, что вы можете ожидать появления версий переходных пакетов в каждом новом выпуске системы. Инструменты разработки программного обеспечения часто попадают в эту категорию, поскольку обновление до новых инструментов по тому же графику, что и системные выпуски, может быть нецелесообразным. Зависимость моей компании от определенных версий GCC, Autoconf и Perl может составлять 5 лет, а моя ОС - 3 года. Поэтому для меня становится легче внедрять новые ОС, если они включают мои старые версии некоторых пакетов в дополнение к тем, которые были актуальны на момент разработки новой ОС.
В других случаях эти серьезные изменения версии происходили давно, в прошлом, и теперь все используют текущую версию. Это в случае с Apache, например. Изменение с 1.3 на 2.0 было гораздо более значительным с точки зрения совместимости, чем любое из изменений версии 2.x, поэтому, как только все перешли на 1.3, больше не было необходимости предлагать несколько версий Apache в рамках данной версии ОС. Но, как только вы все используете apache2
пакет, не очень хороший аргумент для его переименования apache
. Это может привести к ненужным проблемам с обновлением. Кроме того, там, где в прошлом существовала очевидная потребность в предоставлении двух параллельных версий, необходимость, вероятно, повторится в будущем.
Такая практика именования пакетов обычно происходит только с библиотеками или важными основными пакетами. Для большего количества периферийных пакетов вы должны просто обновиться до текущей версии.
С библиотеками чаще обращаются таким образом, чем с приложениями, потому что по своей природе другие пакеты зависят от них. Чем популярнее библиотека, тем более непрактично требовать, чтобы каждый другой пакет, в зависимости от него, перестраивался и связывался с ним только для того, чтобы библиотека могла быть поэтапно обновлена до новой основной версии без этого переходного периода.
Часто, когда приложение обрабатывается таким образом, это происходит потому, что оно содержит элемент библиотеки. Например, Apache - это не просто веб-сервер, он также предоставляет API для разработки плагинов. ( mod_foo
и тому подобное.) Если кто-то имеет старый mod_something
связанный с ABI плагина Apache 1.3 и не обновил его для использования более нового API 2.0, будет удобно, если ваша ОС будет продолжать предлагать старый Apache 1.3, пока у всех создателей плагина не появится шанс обновить свои плагины.