LINUX.ORG.RU

Ubuntu обдумывает внедрение нового формата установочных пакетов

 


0

1

В листе рассылки разработчиков Ubuntu появилось сообщение Колина Уотсона (главного человека в Canonical по вопросам установки системы и отдельных пакетов) о том, что ведется работа над новым, упрощенном форматом прикладных пакетов, с возможностью установки приложений «в один клик». В первую очередь целевыми платформами являются мобильные версии Ubuntu, хотя новая система по планам должна функционировать также на десктопах и даже в других ОС. При этом текущий вариант установки традиционных deb-пакетов должен сущестововать параллельно, использование утилит apt или dpkg все еще останется возможным и безпроблемным.

Введение новых «клик-пакетов» («Click packages») имеет главную цель — максимально упростить сборку пакетов для Ubuntu, забыть о зависимостях, установочных скриптах и разместить каждое приложение в собственном каталоге.

Все это не просто задумки или планы: автор подготовил работающий пример низкоуровневой системы установки подобных пакетов, и вот что в ней примечательного:

  • Никаких взаимных зависимостей между пакетами.
  • Каждое приложение устанавливается в отдельный каталог.
  • Конфигурация установочного пакета пишется в простом декларативном стиле, никаких скриптов.
  • Скорость. Неоптимизированная, написанная на Python система работает приблизительно на полсекунды дольше, чем стандартный dpkg. Сборщик пакетов также написан на Python.
  • Возможность установки пакета от обычного пользовательского аккаунта.
  • Для сборки нужно написать файл-манифест, разместить его в корне каталога с бинарными файлами, после чего произвести сборку с помощью скрипта.

Отмечается, что авторы «клик-установщика» руководствовались наработками проектов Listaller or 0install. Более подробное рассмотрение предложения Колина и его коллег ожидается в ходе его доклада на Ubuntu Developer Summit, который будет проходить с 14 по 16 мая.

>>> Подробности

★★★★★

Проверено: Aceler ()
Последнее исправление: maxcom (всего исправлений: 3)
Ответ на: комментарий от vitalif

Во-вторых, очень многие зависимости «>=» и соответственно более старые пакеты встанут в новую систему.

Нет, потому...

В-третьих, всякие зависимости было бы круто тоже научиться просто дублировать в системе - т.е., ставить несколько версий одной либы. Кстати и костыли с зоопарком всяких libboost1.49, libboost1.50, libboost1.51 и так далее сразу бы ушли в туман.

...что boost не совместим по ABI между версиями. Так что использование libboost1.49, libboost1.50 является вынужденной мерой. Соответственно зависимости с >= может и не найтись, или она будет несовместимой по ABI и вызовет крах приложения при старте.

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

Все извращения прячут от пользователя в виде няшной gui-шной програмки, такой как regedit :)

Эту программу вы называете няшной? Да она по относительно незабитому реестру ищет подстроку по несколько минут.

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

Это regedit-то няшная гуишная конфигурялка? Ы :)))))

Не надо сервисов - не надо плодить лишние сущности и интерфейсы взаимодействия с багами.

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

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

проблема в нвидии

При том, что в KWin вертикальная синхронизация и автоопределение частоты обновления работают замечательно. Конечно, проблема в нвидии.

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

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

Да понятно. Но если бы оно умело само ставиться рядом и не мешать друг другу, был бы один пакет libboost с версиями 1.49, 1.50 и т.п, и зависимость вида «==».

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

Внимание: 4-я версия была выпущена в 2005-м году, и до сих пор остаётся основной. При этом третья ещё достаточно долгое время поддерживалась.

За 5-6 лет можно переделать что угодно. Да и Qt Software не собирается больше делать таких изменений, они и сами прекрасно понимают последствия. У них-то клиенты есть.

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

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

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

Я уверен, что юниксовые древние постулаты не продержатся и пяти лет, а каноникал будут первыми, кто их переступит. И слава, бл*ть Богу.

linuxhater
()
Ответ на: комментарий от pevzi

QtCreator нынче умеет работать через adb с android-смартфонами с битыми серийниками. Эклипс не умеет. Но проблема-то не в эклипсе.

Так что если в KWin работает, это не говорит вообще ни о чём.

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

Путин не заставляет, он вообще наше всё! :DDDDD

Заставляет фантазия - представить, что будет, если весь популярный софт в ОдинПукПакетах будет распространяться. Жуть же.

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

Нормальный подход - это банальное написание GUI к тем конфигам, к которым это нужно.

Имхо, это старый подход. Вот скажи накой мне на сервере держать иксы, да еще и qt впридачу, ради того же iptables. Ладно, берем что-нить более естественное, скажем, ради postfix'а? Вот у меня 100500 серверов только с постфиксом и мне надо ими рулить в полу-автоматическом режиме. Мне что, на каждый сервак конектится через ssh -X -y host и запускать гуишку? Это даже не смешно.

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

Вообще-то запросто найду. QSettings с параметрами приложения и вперёд.

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

Кто угодно, только не пользователь. Им ничто не мешает собирать один дистронезависимый тарбол, который можно распаковать в любое место. Некоторые разработчики ПО предоставляют такой, например Mozilla, Blender, Ardour и др.

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

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

Так предлагается стандартный набор без всяких «вторых» версий. Это полная противополжность тому, что было и остается до сих пор - на десктопе держать и 3ю и 4/5 версии. Что мешает тогда сделать мультиверсионность для gtk ?

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

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

linuxhater
()
Ответ на: комментарий от gh0stwizard

O_O да ты чо, я не об этом. Я о том, чтобы сами конфиги оставить КАК ЕСТЬ и вообще не трогать, а для гуёвой настройки сделать гуёвую тулу. Которая будет генерить обычный нормальный plaintext конфиг.

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

Что мешает тогда сделать мультиверсионность для gtk ?

Тогда уж двухверсионность, версий всего две. Мешает, например, несовместимость стилей в css между минорными версиями gtk3.

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

Которая будет генерить обычный нормальный plaintext конфиг.

А какая разница кто будет генерить конфиг гуишка или отдельный демон со стандартным апи? Или это добавит тормозов? Вобщем, не нравится идея - забудьте что я сказал, я сам сделаю на ней миллионы :)

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

иерархию фс тоже никто не меняет

так давай поменяем (следуя твоей логике).

нужны же новые стратегии!

есть такая клёвая штука - ФантомОС, например!

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

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

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

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

Тогда уж двухверсионность, версий всего две.

Сейчас две, завтра три. Вобщем, есть примеры, где без этого никуда: винда, вендроид. Все они поддерживают старые апи. И очень-очень-очень долго.

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

А, так твои демоны именно конфиги генерить будут? Это да, нормальная идея. Разве что писать м.б дольше/сложнее, засчёт добавления звена.

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

Если в KWin работает, это говорит о том, что баг можно хотя бы временно обойти.

pevzi ★★★★★
()

Ubuntu обдумывает
обдумывает

Значит будет так же как и с rolling-release

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

А, так твои демоны именно конфиги генерить будут?

Ну, все зависит от того сколько людей будут делать. Конечно проще генерировать конфиги, чем переделывать функции чтения этих конфигов... (хотя как посмотреть). На первом этапе это вообще не критичная задача.


- А вы можете запилить такую-то фичу?
- Тодд Говард перед выходом Cкайрим. - Да, давайте нам 3 млн. баксов и мы сделаем это!

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

генерировать конфиги, чем переделывать функции чтения этих конфигов

Ну вот в этом всё кардинальное различие.

Если идея в том, чтобы генерить те конфиги, что уже есть, максимум с мелкими изменениями формата, и генерить их не зависящими ни от чего утилитами - идея нормальная.

Если идея в том, чтобы перепилить всё на**й и посадить весь софт на общий движок конфигурации, к которому прикрутить общий демон управления и общий веб-интерфейс, то идея плохая, т.к. может привести к тому, что на ручное редактирование все забьют толстый болт и править конфиги руками станет невозможно / очень неудобно. А может и мусор сразу расплодиться - гуёвые конфиги этим страдают (вон на KDEшные глянь).

Хотя, UCI в openwrt вроде ничо так - и текстовый, и реестр, и за форматом следят, и говна нет.

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

кстати, а если два пользователя устанавливают одно и то же приложение — оно ставится в двух экземплярах? обалдеть!

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

Одумаются. Они ж не совсем дураки.

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

Разработчики Убунты вон ведь одумались.

Хернёй они страдают, эти разработчики. Систему удобнее для юзеров чем apt-get (rpm, чё там ещё есть?) сложно придумать. Если у разработчика не хватает мозгов её осилить, никто не мешает распространять свой софт по-тупому, без зависимостей, прямо сейчас, без всяких выдумок от canonical.

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

Ну вот в этом всё кардинальное различие.

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

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

С другой стороны, если патчить весь софт, то достаточно раз написать свою функцию чтения конфига, сделать для нее интерфейс и раздать задачу менее квалифицированным разработчикам, чтобы они просто раставили связи. Это упростит процесс перестраивания и ускорит его. Также будет унификация с другой стороны - одна функция, считай одно апи и можно прикрутить ее к одной БД. Все вроде замечательно.

Но, пока не возмешься и не раскопаешь что к чему, я не уверен в 100% успешности второго варианты и останусь на первом.

Куда более важная задача это продумывание самого API для демон-gui/script/etc взаимодействия. Не менее важным всплывает вопрос безопасности. Вобщем, задача интересная и в ней много всякой работы :)

Идея не моя. Все это придумал давным давно чел создавший REST и описавший такую модель в своем дисере (2000-2001 годы, не помню точно). Обычная сервисная архитектура.

В systemd пошли похожим путем, но не так открыто как хотелось. И это связано с тем, что Поттерингу приходится все делать одному, что накладно. Но через год-два у systemd будет отличный интерфейс, которым можно управлять как через gui, так и скрипты, так и веб-морду.

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

Если попробовать поставить Chromium (не Chrome) на оффтопик — так и произойдёт.

beresk_let ★★★★★
()

Объясните популярно кто разбирается в теме: 1. Я так понимаю устранить зависимости можно только путём статической компиляции? Ну если приложение Х требует для работы библиотеку Y версии 4.45.76 то пока её в системе нет приложение то всё равно не заработает. Определяет версию библиотеки необходимой для работы разработчик приложения, а никак не Canonical. Тем более что большая часть пакетов из Debian. Правильно я понимаю что другого пути кроме статической компиляции просто не может быть? 2. Если всё сводится к статической компиляции то кто мешает это делать сейчас в рамках имеющегося пакетного менеджера? И кто мешал делать так раньше? Ну собрали приложение Х вместе с нужной библиотекой, запихнули в deb пакет и всё. Одно приложение - один пакет без всяких зависимостей. Зачем вообще все эти велосипеды? Зачем нужно менять менеджер, формат пакетов?

mbivanyuk ★★★★★
()

Не ведитесь вы на этих тупых тролей уже. Никто не готовит замену deb, это для мелких приложений ubuntu phone. И да, это хорошо. Хорошо главным образом для скриптовых языков, а то сколько тут нытья по поводу установки redmain, например. Единственно, рубисты скажут нафига питон, питонщеги в развертывании приложений-то не смыслят нефига. Любое подобное redmain приложение удобнее установить в отдельный каталог, теперь для этого будет утилита - это хорошо. Плюс система отдельно, малварь отдельно.

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

Пока Mir делается, Wayland уже работает.

В чьем-то сне чтоли.. в моем нет..

special-k ★★★★
()
Ответ на: комментарий от gh0stwizard

Имхо, это старый подход. Вот скажи накой мне на сервере держать иксы, да еще и qt впридачу

AQ Если я не ошибаюсь, Qt и без иксов может. А гуй - для удобства или наглядности. Кое-где это нормально.

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

> Только что отправил на e-mail автора Click Packages своё предложение переименовать DEB в UBU :-)

Your opinion about who has the right to use the .deb extension is not widely shared, and I think Debian would consider such a restriction to be non-free. There is little value in renaming and many reasons not to.

--
Colin Watson

ZenitharChampion ★★★★★
()

ой какие няшки...
пусть ждут адвокатов с яблоками.

решение давно ожидаемое и технически оправданное!!!

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

C++ ... стабильным ABI ... Qt

Вот спасибо, повеселил меня, старика! Напомнить про эпопею сверсиями gcc-c++ и Qt до последней пары лет?

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

Colin Watson, помимо работы в Canonical, также - одна из ключевых фигур в Debian, член технического комитета (правления), debian developper, сопровождающий кучи базовых пакетов

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

В новом формате пакетов Qt определённо попадёт в базовую систему

Qt простите какой версии «попадёт в базовую систему»? И как насчет того, чтобы разработчики Qt приняли обязательство не ломатьбинарную совместимость как минимум в рамках всей 4-й, всей 5-й и всей 6-й версий? И как насчет того, чтобы разработчики gcc не затеяли очередную пертурбацию в name mangling в c++? А какие модули Qt попадут в «стандарт»?

Так что никакого «Qt в стандарте» не будет, не напрягайся.

no-dashi ★★★★★
()

Лучше бы на rpm перешли и в /opt складировали своё проприентарное ПО.

steemandlinux ★★★★★
()

В целом хорошая новость.

STiCKY
()

Before getting too concerned about this latest Canonical move, how it's being promoted right now is to just complement apt/dpkg and to not replace the traditional Debian packages. This new package format and installer would just be for newly-distributed packages, namely third-party software on the Ubuntu Phone/Tablet and written against the Ubuntu SDK.

М-м-м... то есть, это не для десктопа, я так понимаю? Зачем тогда весь этот холивар?

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