LINUX.ORG.RU
ФорумTalks

Решено в два раза сократить время поддержки не LTS-релизов Ubuntu и открыть постоянно обновляемый репозиторий

 


1

0

На состоявшемся несколько часов назад заседании комитета по техническому развитию Ubuntu утверждено решение по сокращению времени поддержки промежуточных выпусков Ubuntu c 18 до 9 месяцев. Время поддержки LTS-выпусков оставлено неизменным. Таким образом, обновления с устранением проблем безопасности для не LTS-релизов будут выпускаться в течение трёх месяцев после выхода следующего выпуска.

При 18-месячном цикле поддержки промежуточных выпусков приходилось поддерживать одновременно 4 выпуска Ubuntu, что отнимало достаточно много ресурсов. По мнению разработчиков 18-месячный цикл поддержки избыточен, так как промежуточные выпуски в основном востребованы пользователями, стремящимися получить наиболее свежий набор программ и достаточно оперативно переходящими на следующий выпуск после его доступности. Для таких пользователей вполне достаточно выпускать обновления только в течение трёх месяцев после релиза. Для тех, кто отдаёт предпочтение стабильности и не спешит совершать переход на новую версию рекомендуется использовать LTS-выпуски, выходящие раз в два года и поддерживаемые 5 лет.

Вторым важным решением стало намерение предоставить пользователям средство для постоянного отслеживания находящихся в разработке выпусков Ubuntu без выполнения единовременного обновления всего дистрибутива. Для пользователей будет доступен постоянно обновляемый репозиторий пакетов, отражающий текущий статус развития находящихся в разработке выпусков дистрибутива. Используя данный репозиторий пользователи смогут поддерживать на своей машине самую свежую экспериментальную редакцию Ubuntu.

Примечательно, что на совещании было явно обозначено, что вышеуказанную схему не следует путать с предлагаемой некоторыми разработчикам модели rolling-обновлений, так как доступ к находящимся в разработке пакетам преследует иную цель, технически не является rolling-релизом и не предусматривает дополнительной стабилизации (идея выпускать каждый месяц стабилизированный срез экспериментального репозитория пока не рассматривалась). Все ранее используемые принципы разработки останутся неизменными и новые промежуточные выпуски по-прежнему будут разрабатываться в рамках фиксированного цикла со всеми сопутствующими стадиями, такими как заморозка пакетов и финальное тестирование. Тем не менее, внедряемые в последние время средства непрерывной интеграции и ежедневного автоматизированного тестирования должны заметно поднять качество находящего в разработке репозитория и сделать его пригодным для постоянного ознакомления заинтересованных энтузиастов с новшествами.
Опеннет

★★★

Полу-rolling какой-то. Посмотрим, что будет со стабильностью.

fang90 ★★★★★ ()

Лучше бы запилили возможность установки приложения любой версии, независимо от версии ОС. И всем пофиг будет на роллинг.

firestarter ★★★☆ ()
Ответ на: комментарий от firestarter

Тут наступают ограничения пакетных систем (всех существующих), ABI и фантазии разработчиков (тот же GIMP использует наипоследнейший gtk, а QtCreator — последний qt4).

Но для софта на Qt или java такое возможно уже сейчас.

quiet_readonly ★★★★ ()

Что ж, посмотрим, будет ли это стоить внимания по сравнению с уже существующими решениями других популярных дистрибутивов Linux или нет.

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от firestarter

> Лучше бы запилили возможность установки приложения любой версии, независимо от версии ОС. И всем пофиг будет на роллинг.

Здесь программ в репозитории не как в Debian'е, но вот.

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от ZenitharChampion

Идея хорошая, но нужно заставить разработчиков приложений использовать это. А это нереально.

firestarter ★★★☆ ()
Ответ на: комментарий от quiet_readonly

Тут наступают ограничения пакетных систем (всех существующих), ABI и фантазии разработчиков (тот же GIMP использует наипоследнейший gtk, а QtCreator — последний qt4).

Нет никаких ограничений. Вот вариант раелизации: собирать приложения статически (или просто тащить необходимые зависимости с собой в своём каталоге) и ставить их в /opt, каждое приложение в свой отдельный каталог. Да, это Шindoшs шay. Можно запилить отдельный репозиторий для таких приложений. Таким образом ты можешь использовать либо очень старое приложение, либо очень новое приложение, несовместимое с версиями библиотек в репах текущей версии твоего дистра. Оно просто несёт нужные ей библиотеки с собой и использует их.

firestarter ★★★☆ ()
Ответ на: комментарий от firestarter

Или можно так. Взять GCC 4.1 и GLIBC 2.4. Обратная совместимость позволит запускать эти бинарники во всех последующих версиях этих библиотек. Взять CentOS 5, взять его стандартные библиотеки. Создать RPM и DEB со стандартными библиотеками, а не входящие в стандарт библиотеки положить прямо в пакет.

Всю проприетарщину нужно компилировать с этими основными библиотеками и этими десктопными библиотеками. В итоге они будут запускаться и в убунте, и в дебиане, и в федоре, и в сьюсе. Причём не важно какой версии, Ubuntu 6.06, Ubuntu 10.10, Ubuntu 12.04... Пример такого бинарника - Adobe Flash Player. Ну как ни бейся, везде запускается, скотина! Или например Desura и игры Braid, Cogs, Osmos, Penumbra, Amnesia, Super Meat Boy, Trine, Zen Bound 2.

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от firestarter

Линуксовые приложения часто взаимодействуют друг с другом и опираются друг на друга, что и является одной из фишек линукса. В описанной схеме оно не пойдёт.

Кроме того, от статической сборки убранные интерфейсы типа OSS не появятся.

quiet_readonly ★★★★ ()
Ответ на: комментарий от quiet_readonly

Линуксовые приложения часто взаимодействуют друг с другом и опираются друг на друга, что и является одной из фишек линукса. В описанной схеме оно не пойдёт.
Кроме того, от статической сборки убранные интерфейсы типа OSS не появятся.

Бред полный. Это тупая идеология, не более. Технически ничто не мешает собрать приложение дистронезависимо так чтобы любой пользователь его мог взять и поставить в любой дистр почти любой версии. Взять например недавно вышедший Ardour 3.0. Я просто скачал с сайта тарбол, распаковал и запускаю /opt/Ardour/Ardour_x86-3.0_14207/bin/ardour3. И плевать пользователь хотел на проблемы зависимостей и взаимодействий. Программа просто берёт и работает, никому не мешает и не заставляет обновить более половины содержимого системы.

firestarter ★★★☆ ()
Ответ на: комментарий от firestarter

NixOS.

Лучше бы запилили возможность установки приложения любой версии, независимо от версии ОС. И всем пофиг будет на роллинг.

NixOS

Camel ★★★★★ ()
Ответ на: комментарий от Deleted

И будет вендузятство со 100500 версиями libpng :}

Тебе то что? Никто же никому ничего не будет навязывать. Если тебе религия не позволяет вендузятство, не устанавливай так, вот и всё. Пользуйся пакетами из дефолтных реп и никакой венды в твоём линуксе.

firestarter ★★★☆ ()
Ответ на: NixOS. от Camel

NixOS

Но зачем, когда можно сделать дистронезависимо и каждый сможет пользоваться в своей системе по желанию? А кто не хочет, будет продолжать использовать то что тают дефолтные репы и грызть кактус.

firestarter ★★★☆ ()
Последнее исправление: firestarter (всего исправлений: 1)

Вообще ничего не понятно про новый репозиторий. Чем это принципиально отличается от обновления до альфы/беты следующего релиза? Или речь о создании чего-то типа дебиановского testing?

metar ★★★ ()
Последнее исправление: metar (всего исправлений: 1)
Ответ на: комментарий от firestarter

Нет никаких ограничений. Вот вариант раелизации: собирать приложения статически (или просто тащить необходимые зависимости с собой в своём каталоге) и ставить их в /opt, каждое приложение в свой отдельный каталог. Да, это Шindoшs шay. Можно запилить отдельный репозиторий для таких приложений. Таким образом ты можешь использовать либо очень старое приложение, либо очень новое приложение, несовместимое с версиями библиотек в репах текущей версии твоего дистра. Оно просто несёт нужные ей библиотеки с собой и использует их.

Пытался собрать свой дистрибутив на основе LFS по этому принципу, но замучился. Оказалось проще перейти на винду.

curufinwe ★★★★★ ()

Неясно только, чем такое решение лучше полного выпила не-LTS релизов + введения полноценного роллинга.

Или, ещё проще, просто выпила не-LTS релизов, если сил на полноценный роллинг пока не хватает...

yura_ts ★★ ()
Последнее исправление: yura_ts (всего исправлений: 1)
Ответ на: комментарий от Deleted

Мне то, что это всё ненужно.

Ещё раз повторяю, никто бы никого не принуждал пользоваться такими пакетами. Кто не хочет — продолжает пользоваться тем что дают дефолтные репы и не разводит у себя венду, грызёт свой кактус дальше.

firestarter ★★★☆ ()
Ответ на: комментарий от firestarter

Тебе нужны какие-то пакеты чтобы распаковать архив с программой и всеми библиотеками, что в неё запихали? До чего дошёл мир.

Deleted ()
Ответ на: комментарий от curufinwe

Пытался собрать свой дистрибутив на основе LFS по этому принципу, но замучился. Оказалось проще перейти на винду.

А смысл? Это реализуемо в любой уже готовой системе. Собираешь правильно приложение, пакуешь в тарбол и готово. Пользователь просто скачивает, распаковывает (или это делает за него специальный пакетный менеджер) куда ему удобно и пользуется. Некоторые умные разработчики так и поступают, например Mozilla, Ardour, Deadbeef и пр. Я просто высказал идею создания для такого рода пакетов отдельный реп, куда бы мейнтейнеры складывали бы самые свежие версии ПО, чтобы пользователи любой версии дистра могли бы им легко воспользоваться.

firestarter ★★★☆ ()
Ответ на: комментарий от Deleted

Тебе нужны какие-то пакеты чтобы распаковать архив с программой и всеми библиотеками, что в неё запихали?

Читать научись.

firestarter ★★★☆ ()

ppa частично переедут в основные репы?

Чтож, всё правильно делают.

Pakostnik ★★★ ()

Ох и зря они, я периодически «засиживылся» на не-lts дистрах т.к.

1) «и так всё работает»

2) нет времени

2) тупо влом каждый раз перепиливать под себя. Свежие пакеты первой необходимости и так собирал из сырцов.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

1) «и так всё работает»

Дистапгрейды ничего не ломают. По крайней мере в Kubuntu (испытал однажды батхёрт только при kde3→kde4).

2) нет времени

Обновление много времени и не занимает, точнее обычно не отвлекает внимание пользователя.

2) тупо влом каждый раз перепиливать под себя.

Зачем, ты же не ставишь систему с нуля.

Свежие пакеты первой необходимости и так собирал из сырцов.

И ни разу не сталкивался с тем что новая версия того что ты собираешь, требует обязательно новые версии каких-то библиотек, которые доступны только в следующей версии дистра? Не собирать же теперь и все зависимости тоже, иначе это уже Гента.

firestarter ★★★☆ ()
Последнее исправление: firestarter (всего исправлений: 2)
Ответ на: комментарий от firestarter

Дистапгрейды ничего не ломают.

Ха-ха, смешная шутка.

требует обязательно новые версии каких-то библиотек, которые доступны только в следующей версии дистра?

именно за это я люто ненавидил убунту. Слава богу мне хватало обновлений по мелочи - свежий питон, какой-нить libevent... Пакетов пять-десять меня обычно не устраивали.

true_admin ★★★★★ ()
Ответ на: комментарий от firestarter

Это единственный способ разработки даже под текущий LTS. Например, мне нах не впился древнейший дистрибутивный буст и берклидб, критически нужны фичи из последних версий, естественно, я это всё буду сам собирать и таскать со своим приложением.

Reset ★★★★★ ()

Вообще, от промежуточных релизов надо либо отказываться полностью либо называть это альфой, technology preview и т.п. будущего LTS, потому что толку от этих релизов всё равно нет никакого, никакой вменяемый человек их не использует.

Reset ★★★★★ ()
Ответ на: комментарий от true_admin

Дистапгрейды ничего не ломают.

Ха-ха, смешная шутка.

Ну я пользуюсь с 2007г., обновляюсь каждые полгода как зарелизится (пропустил лишь один релиз, когда только запилили четвёртые кеды. Слишком уж много было жалоб).

именно за это я люто ненавидил убунту. Слава богу мне хватало обновлений по мелочи - свежий питон, какой-нить libevent... Пакетов пять-десять меня обычно не устраивали.

По мне так проще просто взять из будущих реп нужные библиотеки и бинари и запускать через LD_LIBRARY_PATH (есть ещё вариант с debootstrap и chroot), чем собирать кучу вещей.

firestarter ★★★☆ ()
Ответ на: комментарий от Reset

Это единственный способ разработки даже под текущий LTS. Например, мне нах не впился древнейший дистрибутивный буст и берклидб, критически нужны фичи из последних версий, естественно, я это всё буду сам собирать и таскать со своим приложением.

Не вижу причин собарать LFS всё же. Если нужны новейшие библиотеки, проще воспользоваться debootstrap (поставить будущую версию дистра в отдельный каталог) и chroot.

firestarter ★★★☆ ()
Последнее исправление: firestarter (всего исправлений: 1)
Ответ на: комментарий от firestarter

Не вижу причин собарать LFS всё же

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

Если нужны новейшие библиотеки, проще воспользоваться debootstrap (поставить будущую версию дистра в отдельный каталог) и chroot.

Тоже самое что и с LFS. Поэтому только LTS в качестве базы + свои сборки нужных библиотек вместе с приложением.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Вообще, от промежуточных релизов надо либо отказываться полностью либо называть это альфой, technology preview и т.п. будущего LTS, потому что толку от этих релизов всё равно нет никакого, никакой вменяемый человек их не использует.

Соглашусь. Но, к сожалению, в самом LTS как-то вяло исправляют баги в графических интерфейсах и низкой производительности.

quiet_readonly ★★★★ ()
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от quiet_readonly

Тут наступают ограничения пакетных систем (всех существующих), ABI и фантазии разработчиков (тот же GIMP использует наипоследнейший gtk, а QtCreator — последний qt4).

Вот не надо гнать. В rpm такого ограничения нет.

Nxx ★★★★★ ()
Ответ на: комментарий от Ford_Focus

собери сам. статически слинкуй все нелюходимые библиотеки. какие проблемы?

А с какой стати я должен делать чью-то работу? Собирать пакеты это дело разработчиков или мейнтейнеров. Я в них не записывался.

firestarter ★★★☆ ()
Ответ на: комментарий от Nxx

Вот не надо гнать. В rpm такого ограничения нет.

Причём тут rpm? Если в новой версии какой-то библиотеки опять поменяли API, ABI и прочую хрень, то оно будет так хоть в rpm, хоть в deb, хоть в msi.

firestarter ★★★☆ ()
Ответ на: комментарий от firestarter

они и собрали. если тебя не устраивает существующая сборка - перепакуй в соответствии со своими пожеланиями

Ford_Focus ★★★★★ ()
Ответ на: комментарий от Reset

толку от этих релизов всё равно нет никакого, никакой вменяемый человек их не использует.

Бред. LTS имеет смысл лишь на серверах и может быть ещё где нибудь в энтерпрайзе, где важно один раз поставить и забыть. Для десктопа это не годится, потому что у пользователя часто возникает желание поставить новую версию чего нибудь, а в LTS оно внезапно может не поставиться, потому что требует новых версий библиотек, которые находятся в следующем релизе.

firestarter ★★★☆ ()
Ответ на: комментарий от Reset

В мейлинг листе говорили, что ОЕМам нужны релизы чаще чем раз в два года. Они очевидно должны быть чуть стабильнее, чем срезы потенциального ролинга.

zz ★★★★ ()
Ответ на: комментарий от Nxx

Ты посмотри, на какое утверждение я отвечал.

Ты не понял комментария, на которое отвечал:

Тут наступают ограничения пакетных систем (всех существующих), ABI и фантазии разработчиков (тот же GIMP использует наипоследнейший gtk, а QtCreator — последний qt4).

Вот не надо гнать. В rpm такого ограничения нет.

Человек говорит о недостатках традиционных линуксовых систем зависимостей, когда в одной библиотеке что-то поменялось и приходится все использующую эту библиотеку приложения переписывать, иначе в новый релиз дистра приложение не попадёт.

firestarter ★★★☆ ()
Ответ на: комментарий от firestarter

А с какой стати я должен делать чью-то работу?

А с какой стати кто-то должен делать бесплатно что-то для тебя?

dinn ★★★★★ ()
Ответ на: комментарий от firestarter

Человек говорит о недостатках традиционных линуксовых систем зависимостей, когда в одной библиотеке что-то поменялось и приходится все использующую эту библиотеку приложения переписывать, иначе в новый релиз дистра приложение не попадёт.

Я ответил на утверждение, что это - ограничение пакетных систем.

Nxx ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.