Почему несвежие пакеты на Debian/CentOS это проблема?

Question

[wawa]

Вопрос от виндузятника.
Знакомлюсь с миром линукс и, выбирая дистр для сервера, натыкаюсь на жалобы об устаревших пакетах в CentOS/Debian - типа старый nginx, mysql, etc. Ну хорошо, старые они, но что мешает поставить новые? Тот же PostgreSQL 10.1 на Debian 8 например?
Почему по этим причинам выбирают Ubuntu LTS вместо надежного (как я понял) Debian?

Comments

[Pavel]

тут пишут баги.А кроме багов - уязвимости ещё.
Мешает - не все пакеты так легко обновляются. Пытался я как то на дебиане собрать steamos и забил, из за неразрешённых зависимостей.

P.S. я для сервера ставлю OpenSUSE, пакеты не особо старые,не супер свежие, но зато есть супер удобный yast, который позволяет настроить сервер через консольку не вводя куча команд.(Мне очень нравится настройка файрвола,оч удобно,вместо прописывания iptables вручную)

Answer 1

[Fixid]

LTS - Long-term support - значит долгая поддержка.
В офф репах содержатся оттестированные версии без багов и обычно не ломающие обратные зависимости.
Например ImageMagick постоянно меняет API, и если обновить на более свежий не из офф репы, есть шанс что ваша либо просто не сможет с ней работать.

Хотите свежее, ставьте, ничего не случится. НО есть вероятность будут зависимости которые вы не сможете удовлетворить и софт не поставится.

Пакеты из Debian со временем перетекают в Ubuntu, как только станут стабильными

Comments

[wawa]

"НО есть вероятность будут зависимости которые вы не сможете удовлетворить и софт не поставится."
Fixid можно пожалуйста на пальцах?

[Fixid]

Например вы сидели на redis 3.2.6 из офф репы ubuntu 16.04 и резко захотели поставить redis 4.x
Естественно вы полезли в офф репу и там пусто, значит остается два варианта: билдить самому из исходных кодов и найти готовый deb пакет. Пускай по какой то причине сборка пакетов невозможна/лень.
Начинаем искать готовые и находим на debian.org нужную нам версию. Пытаемся поставить и получаем ошибку, требуется redis-tools определенной версии. Качаем, ставим, поставился redis-tools. Теперь запускаем установку redis-server и опять ошибка! Требуется libatomic1 строго определенной версии, ставим и получаем ошибку, нужен gcc-7 а в репе только gcc-6 и т.д.

Тут или найти готовую стороннюю репу которой можно доверять и она в себе содержит все зависимости или билдить из исходников и решать новые проблемы.

Но если мы перейдем на Debian stretch-backports (нестабильная версия), то там уже пытаются прикрутить redis 4.0 (все нужные либы в репе) и как только получится он появится в Debian stretch со всеми зависимостями.

[wawa]

Fixid а если не лениться и из исходников собрать, то всё норм? или тоже могут появиться какие-то конфликты библиотек?

[Fixid]

wawa, из исходников обычно проблем меньше, но они специфичные + надо иметь всю обвязку компилятора что может доставить не меньше проблем. Хотя именно 4.x вроде как можно собрать на gcc-6, а не gcc-7. Еще не проверял. Там всеравно могут потребоваться -dev версии пакетов зависимостей
Опять же нужны знания для сборки из исходников и за make install в цивилизованном мире вас могут назвать нехорошим человеком. Это реально плохая практика. Нормой считается сборка готового пакета на определенную архитектуру, который в дальнейшем будет установлен вручную через dpkg

Answer 2

[Евгений Вольф]

Почему по этим причинам выбирают Ubuntu LTS вместо надежного (как я понял) Debian?

Надежность - это понятие субъективное в данном случае.

Какая проблема в старых пакетах? - по большому счёту, никакой, кроме того, что они (пакеты) - старые.

Что мешает поставить новые? В целом, - тоже ничего. Но, давайте приведу Вам пример. Вы когда-нибудь пользовались смартфоном на Androide? Если да, я думаю Вы знакомы с такой штукой как "Google play market". А теперь представьте себе, что в этом маркете, все программы будут иметь версии выпущенные несколько лет назад. Что при этом мешает взять и поставить программу с какого-то другого места - в общей сложности - ничего.

Answer 3

[Vitaliy Orlov]

Потому что, никто не хочет собирать "по" и его зависимости руками, все хотят сделать:
yum install "по"
и получить свеженькую версию, в которой исправлены старые баги

Но, разумеется, никто не мешает качнуть ночную сборку "по", скомпилить вручную, потратив пару вечеров на поиск зависимостей и использовать последнюю версию.

Answer 4

[Андрей Павленко]

Тут как бы с двух сторон можно посмотреть.
С одной стороны: новые версии - новые баги. Совместимость программ может внезапно поломаться.
Например, у вас стоял-стоял PHP 5.6, а тут бац - он автоматически обновился на PHP 7.0, где нет библиотеки mysql и весь сайт поломался.
Поэтому некоторые дистрибутивы "перестраховываются", и у них очень старые, но проверенные пакеты.

С другой стороны, новые версии - новые возможности. Часто сталкиваешься с тем, что на сервере стоит версия MySQL 2012 года, а за то время появилось InnoDB таблица в каждом файле, fulltext в InnoDB, нативная поддержка JSON. А все это использовать не можешь, так как дистрибутив до сих пор не поддерживает этот новый пакет и нужно устанавливать сторонний, который не факт, что сработает как нужно.
В итоге обновление на новые пакеты становится невозможным без танцов с бубном и ломается вообще идея репозиториев (ведь вместо простой установки в командной строке нужно лазить по интернету и искать репозитории и читать о существующих багах в новых пакетах).
Да, есть backports, есть репы с более новыми версиями - таким образом проблема решается и довольно удобно. Но оно все редко включено по дефолту, что вызывает у новичков сложности.