%20%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D1%8E%D1%82%2F%D1%82%D1%80%D0%B5%D0%B1%D1%83%D1%8E%D1%82%20%D0%BF%D0%BE%D0%BB%D0%BD%D1%83%D1%8E%20%D0%BF%D0%B5%D1%80%D0%B5%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D1%83%20%D0%BF%D1%80%D0%B8%20%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B8%20%D0%B4%D0%BE%20%D0%BD%D0%BE%D0%B2%D0%BE%D0%B9%20%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8%3F.png)
Проведя большую часть своей жизни в Linux, используя Debian, я посмотрел на другие дистрибутивы и был действительно удивлен, насколько они не обеспечивают плавного обновления между версиями. Debian можно обновлять бесконечно, и я уже обновился через несколько основных стабильных версий.
Я говорю о хорошо поддерживаемых дистрибутивах, таких как Fedora (и производных), даже Ubuntu и производных. Даже о стабильных серверных дистрибутивах, таких как CentOS.
Может быть, это потому, что система управления пакетами Debian и скрипты обновления пакетов намного более продвинуты, чем все, что могут предложить другие дистрибутивы?
Или переустановка с нуля при обновлении основной версии просто лучшая идея в целом, независимо от дистрибутива?
решение1
Это сочетание ряда факторов.
Большинство дистрибутивов используют основные релизы как время для внедрения значительных, иногда критических изменений. Например, Fedora 15 добавила systemd, а Ubuntu добавила upstart в 6.10. Debian — очень консервативный дистрибутив во многих отношениях. Крупные, критические изменения не одобряются.
Например, именно поэтому циклы выпуска Debian так сильно разнятся, поскольку они требуют изменения каждого важного пакета для соответствия стандартам нового выпуска.
Технология управления пакетами Debian не превосходит Fedora или Ubuntu (что очевидно, поскольку она такая же, как в Ubuntu), но в Debian решили, что в культурном плане важно иметь плавную систему обновлений.
решение2
Если говорить точнее, я столкнулся с проблемами во многих дистрибутивах при выполнении обновлений. Например, Ubuntu радикально меняет свою установленную базу пакетов между выпусками. Если вы выполните традиционный «dist-upgrade», установленные пакеты обновятся до своих новых выпусков, но в конечном результате не будет новых изменений в составе. Если пакет из установки по умолчанию будет понижен до просто «поддерживаемого» или, что еще хуже, «неподдерживаемого», вы все равно сохраните этот пакет. Если новый пакет теперь находится в установке по умолчанию, он у вас не будет установлен. Даже если ваш выпуск «технически» является обновленным выпуском, он не отражает опыт нового выпуска. Тот же случай также очень точен: при сравнении CentOS5 с CentOS6 они полностью реорганизовали свои имена пакетов.
Debian отдает приоритет плавным обновлениям, ценой таких радикальных изменений. Вот почему Debian медленнее с новыми функциями, для их сообщества компромисс приемлем. Повторяя предыдущий ответ, это не имеет ничего общего с технологией управления пакетами как таковой. Я скажу, что постоянные переустановки Ubuntu меня утомляют.
решение3
То, что вы утверждаете, не относится ко всей семьескользящий релизраспределения.
Для программного обеспечения для обслуживания системы гораздо сложнее решать проблемы совместимости между пакетами при обновлении только некоторых частей системы или поддерживать согласованность конфигурации во время обновлений. Различные программные пакеты должны быть адаптированы для хорошей работы друг с другом.
Вот почему самый простой (т.е.наиболее надежный при тех же затратах времени на разработку) решение для предоставления обновления системы заключается в периодической подготовке полного, тщательно протестированного, полностью инсталляционного релиза. Корпоративные решения, такие как Red Hat, придерживаются позиции, что клиент должен получить надежную систему и не беспокоиться о прерывании обновлений как можно дольше. (Разумеется, незначительные обновления и исправления ошибок должны быть доступны или даже автоматически извлекаться). Это также общая философия, лежащая в основе бесплатных серверных дистрибутивов, таких как CentOS.
Предоставление конечному пользователю бесшовного пути обновления между релизами является большой проблемой для разработчиков системы. Многие дистрибутивы предпочитают не жертвовать своим скудным временем на это. Многие популярные пакеты (например, QT) трудно обновлять, часто требуя полной переустановки. Что еще важнее, многие проекты демонстрируют снижение усилий по разработке или иным образом вытесняются новыми технологиями. В случае системных пакетов это часто требует значительной переработки системы. Процедуры миграции могут быть особенно сложными для реализации, если они должны учитывать тот факт, что некоторые люди захотят обновиться с версии C на D, но другие будут переключаться с B или с A или с какого-то пользовательского состояния в середине.
Итак, как вы уже могли догадаться, наиболее сложный подход — это плавающий релиз. Я не знаю подробностей подхода Debian, но из вашего описания я вижу, что они где-то посередине.