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)

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

его можно сделать в Линуксах чисто уже имеющимися средствами, даже ничего не изобретая

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

Например, организовать возможность «закрепления» определенной версии библиотеки за определенным приложением

То получиться классический DLL Hell, наиболее простое решение - как раз держать библиотеки рядом с приложением, а не в системе

TEX ★★★
()

Убунта превращается в винду!
Закопать!
Зависимости - это хорошо!
Все убунтоиды должны умереть!

anonymous
()

Эй, кто там смеет пытаться упороться сильнее Поттеринга?

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

Qt простите какой версии «попадёт в базовую систему»? И как насчет того, чтобы разработчики Qt приняли обязательство

И второй вопрос — а зачем? Если в базовую систему попадёт libxyz версии abcd, то все пакеты для данной базовой системы будут собраны для этой версии. Точка, абзац, зачем нам новые версии?

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

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

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

да что ж вы тугие такие

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

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

а в комплекте с пакетом будут идти какие-то специфические довески, которые используются чисто этим пакетом

anonymous
()
Ответ на: комментарий от Adonai

third-party software on the Ubuntu Phone/Tablet

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

всё развитие смартфонов в гаджеты для всего намекает что скоро десктопа, как такового, не останется

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

Ну на LSB и FHS все же забили болт (Спасибо Red Hat). Даешь зоопарк, бинарные конфиги и антивирусы! Без них ведь vendor-lockin и выкачку бабла за воздух никааак не осуществить.

И через 10 лет у вас спросят чем Linux отличается от других и вы ответите: обоями.

Стыдно.

anonymous
()
Ответ на: комментарий от Etch

Ну, например, тем, что разрешение зависимостей - это математически неразрешимая задача. Поэтому проще их не иметь, или иметь самый минимум, вроде самых популярных фреймворков, как сделано, например, в Windows.

anonymous
()

У dpkg много фундаментальных кривостей, заставляющих и разработчиков дважды вставать, и юзеров делать лишние телодвижения, вместо использования ПО. Одобряю инициативу.

anonymous
()
Ответ на: комментарий от mbivanyuk

Я думаю что в лучшем случае будет та же гента со сброкой в облаке.

Иначе каждый калькулятор или аудиоплеер будет тянуть за собой все зависимости. Места на диске жто отожрет минимум в 3 раза больше. Я не уверен на счет памяти - процедуры из shared библиотек копируются прииспользовании или нет? Если нет - убунтовские нововведения отожрут всю оперативу(или как минимум увеличат её потребление и никакие гигабайты вас не спасут.) Из того что я вижу в wiki: Library code may be shared in memory by multiple processes as well as on disk

В случае с нововведением кроме диска пострадает еще и потребление оперативки.

anonymous
()
Ответ на: комментарий от BattleCoder

GLIBC?

gentoo, portage, slots

правда, в случае с gimp (который в официальном дереве) такого нет, но можно ебилды переписать, и ставить в систему хоть 10 версий gimp.

с python такое работает, к примеру, и с множеством других пакетов

Только не работает с главной системной библиотекой. По крайней мере, пару лет назад не работало. А так захочешь поставить свежий софт, а он новую версию GLIBC требует, а с ней старый софт не работает... И получается, что захотел какую-то мелочь на 100кб обновить, а приходится обновлять всю систему, т.к. в генте параллельно 2 системных библиотеки (ака glibc) держать было нельзя.

Нет, конечно же, таскать все либы с приложением тоже не вариант, только dll-hell всё-таки существует, и отрицать его очевидное существование глупо. В той же винде, кстати, несмотря на распространённый подход «1 приложение = 1 каталог», и поныне здравствуют и используются разделяемые библиотеки.

RoadRunner
()
Ответ на: комментарий от anonymous

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

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

Valkeru ★★★★
()

А что будет с обновлениями безопасности для такого вот софта? Как по мне, то пакетный менагер меня устраивает почти на 100%

OperaSoftvvare ★★
()

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

Вот тогда в и скажете зависимости это хорошо или плохо.

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

И как насчет того, чтобы разработчики Qt приняли обязательство не ломатьбинарную совместимость как минимум в рамках всей 4-й, всей 5-й и всей 6-й версий?

Они не ломают вообще-то. Изменение name mangling было очень давно и в дальнейших изменениях не требуется.

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

Вы отрицаете очевидное.

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

Ты не понял. Они теперь будут включены в _КАЖДЫЙ_ пакет и занимать будут 100500*кол-во_пакетов.

Заявление не соответствует действительности. Как я уже говорил, современный кроссплатформенный софт уже имеет минимум зависимостей, а остальное настроено на статическую компиляцию — из-за windows и mac. Так что дублирование библиотек в пакетах будет ровно тем же, что и прежде, если учесть наличие базовой системы.

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

а я за последние два года живьём видел кучу гентушников пару маководов и одного пользователя убунты и одного арчевода. Мне можно начинать делать выводы?

qnikst ★★★★★
()

Отличная новость.

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

Надеюсь будут три варианта установки программ: 1. Одним пакетом со всеми зависимостями внутри. 2. apt-get install, вытягивающий программу со всеми зависимостями из репов, на лету формирующий пакет и ставящий его по алгоритму пункта один. 3. apt-get install, ставящий программу «как обычно»

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

D_Lans
()
Ответ на: комментарий от Aceler

а ты сидишь и ждёшь ебилдов.

Напиши свой, читай подправь ebuild от старой версии и положи в локальный оверлей.

Зачем пользоваться source-based дистрибутивом, если не можешь написать необходимый файл для установки из исходников нужной тебе программы ?

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

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

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

D_Lans
()
Ответ на: комментарий от I-Love-Microsoft

С нетерпением жду нового пакетного менеджера

так у этой идеи нет пакетного менеджера, как и у macos. А deb будет таким же, как .pkg.

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

скоро так и терминал уберём а потом и рута, будем как в винде сидеть в песочнице с дырами .

В винде есть и терминал, и рут. Песочница есть в Linux, даже несколько, на выбор.

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

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

eternity
()

Никаких взаимных зависимостей между пакетами.

т.е. каждое приложение будет весить огого?

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

А что будет с обновлениями безопасности для такого вот софта? Как по мне, то пакетный менагер меня устраивает почти на 100

Сколько патчей для устранения проблем с безопасностью в QtCreator накатили разработчики всех линуксовых дистрибутивов? Да я сам отвечу: ноль. Аналогично с игровым движком OpenMW. Полагаю, что и в игрушке 0ad ситуация не отличается.

Обновлений безопасности любого софта в системе не было никогда, это миф. Есть лишь некоторая группа софта, который покрывается подобным, и он в общем-то так и останется на deb с зависимостями, потому что для того же mysql скрипты в пакете и зависимости крайне полезны.

quiet_readonly ★★★★
()

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

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

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

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

У Linux и Unix есть принцип KISS, Keep It Simple, Stupid .

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

В общем Ubuntu быстрее закопается.

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

One-application OS

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

Идея гипотетическая, помидоры просьба не кидать.

RoadRunner
()
Ответ на: комментарий от kostik87

Вот только как раз таки программа в пакете all-in-one больше соответствует принципу KISS, чем когда она раскидана по всей файловой системе а для её управления (установка, обновление, удаление) нужно использовать сложные программы, которые с легкой подачи пользователя могут выдать тоскливую портянку ошибок.

D_Lans
()
Ответ на: комментарий от kostik87

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

Согласен, но в текущей ситуации, чтобы поставить пакет не из репозиториев, нужно пройти 7 кругов ада, удовлетворяя зависимости.

То, что задумали эти ребята, нельзя назвать идеальным. Но это трезвая (или не очень? :)) попытка решить проблему, которая объективно существует. Даже если ничего не получится, сообщество получит опыт, который пригодится после. Да, KISS принцип хорош, но сейчас у Linux есть не меньше недостатков, чем у винды. Более того - я вижу всего один единственный плюс - открытость.

eternity
()
Ответ на: комментарий от los_nikos

нашел старый диск на 20 ГБ, ему уже лет 10 - работает зараза и очень хорошо работает.

sergey19622008
()

Уже неплоха идея разделения системных и прикладных пакетов, которая используется сейчас. Создавать вот такой ужас не надо.

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

хороший вопрос. Т.к. qt-creator у меня не стоит и ставить не хочется, то попробую погадать по кофейной гуще^W^W ебилду.

Тут поддерживаются плагины: autotoolsprojectmanager, cmakeprojectmanager. С судя по ебилду из подмодулей ничего не загружается (это про 2.7.0). Так что вполне возможно и нету, полезный проект, сабмитить баг?

В 9999 (live версия) нужно смотреть как работает git-eclass насколько я помню, он сабмодули загружает.

Ну и если я правильно понимаю, то получается, что в одной и той же версии qt-creator может быть разный qbsprojectmanager в зависимости от того, когда собирали?

qnikst ★★★★★
()

пака убунта, превед ищо адна венда

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

ну если единственный плюс - открытость... поздравляю! вы прозорливый пользователь.

Ну ладно, еще бесплатность :) Просто исторически сложилось, что я работаю на разных системах, и с того времени, когда вышла семерка, с винды я не плююсь. Мне не нужно быть Ъ - я просто «работаю свою работу».

eternity
()
Ответ на: комментарий от D_Lans

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

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

В случае же если у вас будет большой «толстый» пакет, в который включены необходимые библиотеки вам нужно будет переустанавливать этот пакет целиком, а не обновлять лишь библиотеку и так с каждым «толстым» пакетом.

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

Это всё на совести разработчиков и мантейнеров пакетов. Пользователю должно быть по барабану, какой скрипт и как обсчитывает зависимости.

Вы опять смотрите на вещи глазами пользователя, на которые этот пользователь вообще не должен смотреть и знать, тем более пользователь Ubuntu.

kostik87 ★★★★★
()

Идея установки пакетов без зависимостей неплохая. На одной из разновидностей BSD прошла ведь. НО нельзя давать возможность установки пакета от обычного пользовательского аккаунта. Это называется здравствуйте вирусы под Ubuntu?

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

не переживай, копируют 100% мOSX.
Как я понял там pkg от Фряхи и «вот это».

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

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

И вам надо повторить, что в реальном софте библиотеки не будут дублироваться либо уже дублируются, потому что софт кроссплатформенный и пишется также под Windows/Mac?

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