Ричард Хьюз (Richard Hughes), создатель проекта PackageKit (http://www.packagekit.org/), представил (https://blogs.gnome.org/hughsie/2013/03/05/gnome-software-ov.../) первые наработки по реализации проекта GNOME Software (https://git.gnome.org/browse/gnome-software/), в рамках которого развивается низкоуровневая прослойка и интерфейс для установки программ для GNOME. Особенностью GNOME Software является возможность работы как со стандартными механизмами управления пакетами дистрибутивов, работая в роли надстройки над PackageKit и AppStream (http://www.opennet.me/opennews/art.shtml?num=35000), так и задействование средств для обособленной установки самодостаточных пакетов программ, распространяемых в универсальных форматах, независимых от дистрибутивов Linux. Функциональность GNOME Software формируется через подключение плагинов, например, могут быть созданы плагины для показа скриншотов, учёта популярности приложения, формирования рейтинга, интеграции с внешними системами сборки и т.п.
В качестве механизмов для установки программ без привязки к дистрибутивам обеспечена возможность использования систем Listaller (http://listaller.tenstral.net/) и Glick2 (http://people.gnome.org/~alexl/glick2/). Listaller позволяет формировать устанавливаемые в различных дистрибутивах ipk-пакеты (http://www.handhelds.org/moin/moin.cgi/Ipkg), с доустановкой необходимых для работы программы зависимостей из штатных репозиториев дистрибутвов. Glick2 предоставляет средства для формирования самодостаточных пакетов, включающих в себя все необходимые для работы зависимости и способных работать через распаковку в поддиректорию домашнего каталога пользователя. Дополнительно обеспечена интеграция с системой сборки образов операционных систем OSTree (https://ostree.gnome.org/).<center><a href="https://blogs.gnome.org/hughsie/files/2013/03/design.png&quo... src="http://www.opennet.me/opennews/pics_base/0_1363017973.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
URL: https://blogs.gnome.org/hughsie/2013/03/05/gnome-software-ov.../
Новость: http://www.opennet.me/opennews/art.shtml?num=36361
Единственное, что я делаю c PackageKit с момента его появления - сношу его сразу после установки системы. Теперь сносить придется больше...
> Единственное, что я делаю c PackageKit с момента его появления - сношу
> его сразу после установки системы. Теперь сносить придется больше...зачем сносите?
чтобы случайно так не получилось, что Вам захочиться этим воспользоваться? :-)
....тип как например -- """а отрежу-ка я себе мезинец на руке! ведь всё равно я не использую 10-типальцовую печать на клавиатуре..""" :-)
страх перед тем что в будущем ВДРУГ Вам захочется умышленно воспользоваться PackageKit (например через новую программу, которая использует PackageKit) -- не ужеле настолько сильный!? :-)
>> захочитьсяПростите, но это уже слишком...) Перечитывайте, хотя бы, перед отправкой.
А по теме: Мне одному кажется, что они лезут не в свое дело? Может, пользователь, все же, не идиот и сам разберется, как ему программы ставить?
Как бы вам не хотелось, но среднестатистический пользователь в вашем понимании идиот. И он не хочет разбираться как ставить программу, он хочет ей пользоваться.Благо это не OsX (мало пользовался продукцией от Apple, но такое ощущение что для них все пользователи непроходимые тупицы). И у вас есть возможность выбора что и как ставить, это для тех кому лень разбираться, а пользоваться хочется.
С таким же успехом можно упрекнуть любой пакетный менеджер.
>С таким же успехом можно упрекнуть любой пакетный менеджер.Так я, праведный Слаковод, так и делаю!
>И он не хочет разбираться как ставить программу, он хочет ей пользоваться.Поэтому давайте вкрячим ещё один способ установки софта, на этот раз не системный. Чтобы, значится, от разбирательств к использованию этому самому «среднестатистическому» (кстати, вы проводили исследования, либо же вам просто слово нравится?) приходилось преодолевать ещё больше препятствий?
P.S. Третьегномодевелоперы невменяемы совершенно. Мигель, забери их с собой, а?
Точно, который год это поделие приходится выкорчёвывать, оно так и не научилось работать.
Нехай Гноме всё это добро себе забирает.
Гномовцы наращивают функционал? Быть того не может!
Разработчики СПО делают то, что им интересно и нужно. Вам важна стабильность и исправление ошибок ? Подключайтесь к тестированию и выявлению патчей. Или покупайте коммерческий саппорт и вам за денежку все мешающие вам проблемы исправят. Но просто трындеть, что вам что-то должны, не стоит.
так эти гномосеки невменяемы же совершенно. им что патчи, что полька-бабочка…
ссылки на твои непринятые патчи будут или как всегда?
> ссылки на твои непринятые патчи будут или как всегда?сложно давать ссылку на личную переписку с автором «бэкпортированой» в gtk2 идиотии. впрочем, там ничего особо интересного: он упоротый.
>выявлению патчейИмелось ввиду "отправлению"? Патчи с реальными улучшениями состоят исключительно из отмены их коммитов. Будут ли они их принимать?
> Единственное, что я делаю c PackageKit с момента его появления - сношу
> его сразу после установки системы. Теперь сносить придется больше...А я ставлю нетинсталлом, и мне ничего сносить не приходится, просто не ставлю чего попало.
> средства для формирования самодостаточных пакетов, включающих в себя все необходимые для работы зависимости и способных работать через распаковку в поддиректорию домашнего каталога пользователяКонечно, сейчас на меня вызверятся Ъ-линуксоиды, но я всё же скажу крамольную вещь: давно пора это сделать.
Потому что лёгкость установки, независимость от дистрибутива, отсутствие необходимости постоянно качать зависимости и вечной привязки к репозиториям — это то, что будет способствовать росту популярности линукса среди широких слоёв народонаселения.
Нередко доходит до совсем уж непонятных вещей. Пакет xsane-common не используется ничем, кроме xsane. Вообще ничем. Почему бы содержимое не объединить в один пакет? Так нет же, надо разбить на два и создать искусственно зависимость, совершенно ничем не оправданную.
И если у пользователя нет коннекта или серверы с репозиториями прилегли отдохнуть, но нужно срочно сканер поднять, то сначала надо ставить xsane-common, а только потом xsane, иначе, видите ли, зависимость не удовлетворена.
Есть и другая негативная сторона с зависимостями — безумное самоуправство мэйнтейнеров. Скажем, пытаюсь в Xubuntu поставить Cheese, чтобы племянник поигрался с веб-камерой, а эта зараза в зависимостях тянет, кроме кодеков, Nautilus и Zeitgeist. Ну на кой ляд это в Xubuntu?! неужели программа для записи с камеры должна зависеть от файлового менеджера и системного соглядатая? Это что, системные библиотеки? Ну бред же!
Так что пусть гномовцы осуществляют свой проект, желаю им успеха! Множеству школьников, домохозяек, пенсионеров, обычных людей разных профессий не придётся собирать нужный софт из исходников в случае бардака с зависимостями.
> давно пора это сделать.совершенно верно!
> Пакет xsane-common не используется ничем, кроме xsane. Вообще ничем.
а это кстате потому что систему пекетов НЕ возможно сделать одновременно:
* гибкой и автоматизированной.
* не гибкой, но удобной для ручных телодвижений установок/удалений (см. Slackware).
и именно ПО ЭТОЙ причине (по причине вышеупомянутой невозможности) -- нужно чтобы в операционной системы было бы одновременно ДВЕ системы пакетов. (пользоваться сразу ими двумя не обязательно, но иметь ВОЗМОЖНОСТЬ -- надо :)).
============================================================
а что касается системной автоматизированной системы пакетов, в которой существует одновременно и xsane и xsane-common -- то вот конкретно для этой системы пакетов -- это всё правильно! в случае системного манагера пакетов -- каждая программа должна быть разделена как минимум на 2 пакета.
один пакет нужен для пользователя, второй пакет должен содержать внутренню техничускую функциональность...
...как раз для того чтобы если и надо было бы установить по зависимости "Nautilus и Zeitgeist", то чтобы ставились бы лишь библиотеки nautilus-common (название выдуманно) и zeitgeist-common (название выдуманно) , а не целые программы :-)
но это только для системных манагеров пакетов такое позволительно!
а для сторонних программ Программиста Васи Пупкина -- такая система врятли подходит! и именно для его программ -- нужная паралельная другая система самодостаточных пакетов! которую надеюсь сделают успешно :).
Надо не "common"-пакеты лепить, а слабые зависимости делать, чтобы в случае наличия компонента он использовался, а в случае отсутствия - можно было легко понять, какая функциональность недоступна и удобным образом доустановить нужное. Это раз. А второе - программы Программиста Васи Пупкина вообще не должны быть. Либо ты попадаешь в репозиторий, либо иди лесом. А давать неквалифицированному люду возможность принимать хоть какие-то технические решения - неправильно и чревато.
> а для сторонних программ Программиста Васи Пупкина — такая система врятли подходит!
> и именно для его программ — нужная паралельная другая система самодостаточных
> пакетов! которую надеюсь сделают успешно :).так уже. ты до сих пор не знаешь, где купить винду, что ли?
Сорри, сообщение 1.19 было ответом на этот пост.
> Нередко доходит до совсем уж непонятных вещей. Пакет xsane-common не используется ничем,
> кроме xsane. Вообще ничем. Почему бы содержимое не объединить в один
> пакет? Так нет же, надо разбить на два и создать искусственно
> зависимость, совершенно ничем не оправданную.если ты чего-то не понимаешь, то есть большая вероятность, что это вовсе не авторы непонятного дураки.
> если ты чего-то не понимаешь, то есть большая вероятность, что это вовсе
> не авторы непонятного дураки.Однако есть вероятность, что авторы непонятного всё же дураки, правда? :)
> Однако есть вероятность, что авторы непонятного всё же дураки, правда? :)есть. но не в обсуждаемом случае.
>> Однако есть вероятность, что авторы непонятного всё же дураки, правда? :)
> есть. но не в обсуждаемом случае.Ну, насчёт обсуждаемого случая, я бы не был столь уверен. С авторов спрос всяко больше, в плане интеллекта, нежели с простых юзеров.
бебиан. интеллект. OpenSSL. бугога.
>сначала надо ставить xsane-common, а только потом xsane, иначе, видите ли, зависимость не удовлетворена.Где ты об этом прочитал? Чтобы поставить xsane, да нужно поставить xsane-common, только меня лично это нисколько не беспокоит, потому что я говорю лишь то, что мне нужно, а о зависимостях система думает сама. Когда нет репозиториев, есть дистрибутивные диски с репозиториями.
>Скажем, пытаюсь в Xubuntu поставить Cheese, чтобы племянник поигрался с веб-камерой, а эта зараза в зависимостях тянет, кроме кодеков, Nautilus и Zeitgeist. Ну на кой ляд это в Xubuntu?!
Ну то есть дело в том, что ты пользуешься Xubuntu? Или дело в том, что ты не понимаешь разницы между зависимостями типа required, recommended и suggests? Нужно всего-то взять правильный дистрибутив (я использую не перепев Битлс от Мойши, а оригинал - Debian) и почитать как минимум об этих трёх видах зависимостей.
>Так что пусть гномовцы осуществляют свой проект, желаю им успеха! Множеству школьников, домохозяек, пенсионеров, обычных людей разных профессий не придётся собирать нужный софт из исходников в случае бардака с зависимостями.
Дооо! Конечно же это правильно, вместо разгребания одного бардака устроить ещё один дополнительный. Проблема не в сортирах, а в головах. Когда головы вылечат, тогда и сортиры станут чистыми.
> Нужно всего-то взять правильный дистрибутивРжунимагу.
Ъ такие Ъ...
> Нередко доходит до совсем уж непонятных вещей. Пакет xsane-common не используется ничем,
> кроме xsane. Вообще ничем. Почему бы содержимое не объединить в один
> пакет? Так нет же, надо разбить на два и создать искусственно
> зависимость, совершенно ничем не оправданную.Оправданную. В xsane-common входят архитектурно-независимые данные, что позволяет ограницить объём лишних данных при поддержке нескольких архитектур. Ладно убунту, их там три всего, но пакет-то из дебиана, а там этих архитектур штук 10 как минимум... Вот и минимизируют так, пакетов ведь много таких.
> Оправданную. В xsane-common входят архитектурно-независимые данные, что позволяет ограницить
> объём лишних данных при поддержке нескольких архитектур.Эти ваши архитектурно независимые данные весят в упакованном виде 1,772.2 kB
Пруф: http://packages.ubuntu.com/precise/xsane-common
Поэтому, если в пакет не вставляется 1,772.2 kB, то это явно повод, а не причина.> три всего, но пакет-то из дебиана, а там этих архитектур штук
> 10 как минимум...http://packages.debian.org/squeeze/xsane-common
Вес пакета практически тот же: 1,777.3 kBПовод раздробить. Не причина, а именно повод.
> Повод раздробить. Не причина, а именно повод.Лень смотреть в debian policy или maintainer's guide или как там в точности документ называется, но припоминается наличие и указания, и критериев выделения noarch-части.
То, что их могли не трогать с времён 1.2, не повод избегать выполнения ;-) (ну и полтора метра даже и сейчас может быть смысл выделять, если остальное занимает ещё меньше -- вот сто килобайт уже точно не стал бы)
> Есть и другая негативная сторона с зависимостями — безумное самоуправство мэйнтейнеров.
> Скажем, пытаюсь в Xubuntu поставить Cheese, чтобы племянник поигрался с веб-камерой,
> а эта зараза в зависимостях тянет, кроме кодеков, Nautilus и Zeitgeist.
> Ну на кой ляд это в Xubuntu?! неужели программа для записи
> с камеры должна зависеть от файлового менеджера и системного соглядатая? Это
> что, системные библиотеки? Ну бред же!Сейчас лично проверил, нет там таких депендов. Только рекомендации из каких-то там gnome-овских либов. Которые можно просто не устанавливать (а лучше вообще отключить их автоустановку в менеджере пакетов).
> Конечно, сейчас на меня вызверятся Ъ-линуксоиды, но я всё же скажу крамольную
> вещь: давно пора это сделать.Сказал ты вещь не «крамольную», а просто глупую. Сейчас объясню, в чём её глупость.
> Потому что лёгкость установки, независимость от дистрибутива
Лёгкость установки чего? Вместо единственного пакетного менеджера, центра приложений, etc., ты предлагаешь собственный механизм для любой мелочи?! Т.е. гномософт устанавливается и обновляется вот так, кедософт вот так, а вон та куча софтин каждая по своему? Зайди в гуй номер раз, поставь галочку, зайди в гуй номер два — поставь две галочки, зайди в гуй номер десять — поставь сто галочек. Надо всё это сделать удалённо из консоли — возьми моток витой пары и табуретку. А они ведь ещё и обновляться на перегонки лезть будут. И всё это вместо единообразного способа установки? Где тут простота? С какой стороны?
>отсутствие необходимости
> постоянно качать зависимостиЗависимостями занимается пакетный менеджер.
>и вечной привязки к репозиториям — это
> то, что будет способствовать росту популярности линукса среди широких слоёв народонаселения.Да пусть эти широкие слои населения обходят линукс за километр! Ты винду видел у этих широких масс? Загаженное троянами и червями непонятно что, с багами и дырами много-годичной давности. Потому что «нет привязки к репозиториям», и один и тот же набор дерьма таскается с винта на винт годами. При том, что на серверах разработчиков исправленные версии давным-давно есть.
> Нередко доходит до совсем уж непонятных вещей. Пакет xsane-common не используется ничем,
> кроме xsane. Вообще ничем. Почему бы содержимое не объединить в один
> пакет? Так нет же, надо разбить на два и создать искусственно
> зависимость, совершенно ничем не оправданную.Это мелкий недостаток неплохой, в целом, системы. Надо его исправлять, а не ломать уже работающее в пользу третьегномьего ужаса.
UP: Хотя выше лучше объяснили.
> И если у пользователя нет коннекта или серверы с репозиториями прилегли отдохнуть,
> но нужно срочно сканер поднять, то сначала надо ставить xsane-common, а
> только потом xsane, иначе, видите ли, зависимость не удовлетворена.Все нужные пакеты в один каталог и rpm -ihv --nodeps --force *
> Есть и другая негативная сторона с зависимостями — безумное самоуправство мэйнтейнеров.
> Скажем, пытаюсь в Xubuntu поставить Cheese, чтобы племянник поигрался с веб-камерой,
> а эта зараза в зависимостях тянет, кроме кодеков, Nautilus и Zeitgeist.
> Ну на кой ляд это в Xubuntu?Это (не очень) мелкий недостаток неплохой, в целом, системы. Надо его исправлять, а не ломать уже работающее в пользу третьегномьего ужаса.
UP: Хотя выше лучше объяснили.
> Так что пусть гномовцы осуществляют свой проект, желаю им успеха! Множеству школьников,
> домохозяек, пенсионеров, обычных людей разных профессий не придётся собирать нужный софт
> из исходников в случае бардака с зависимостями.Пусть сидят на винде. Пусть сидят на макоси. Не нравится?! А раз не нравится, хрена ли свои порядки тащить оттуда? Напоминает поведение мигрантов из исламских стран — сами от тамошних порядков сваливают в ужасе, но стоит чуть обжиться в мало-мальски приличной стране, так начинают строить вокруг привычный ад.
> Лёгкость установки чего? Вместо единственного пакетного менеджера, центра приложений,
> etc., ты предлагаешь собственный механизм для любой мелочи?!Здесь сложнее, начали скриптовые языки. Не готов сейчас писать развёрнуто, т.к. объём получится большой, а толку скорее ноль.
>> Конечно, сейчас на меня вызверятся Ъ-линуксоиды, но я всё же скажу крамольную
>> вещь: давно пора это сделать.
> Сказал ты вещь не «крамольную», а просто глупую. Сейчас объясню, в чём
> её глупость.Вот же какой глупый Google, свой браузер Chrome поставляет ОДНИМ пакетом, где есть ВСЁ необходимое для работы.
И Opera, внезапно, тоже!
Расскажите Google, какие они идиоты, позволяют хомячкам скачивать готовую программу и не трахаться с зависимостями!
А ещё слыхали о таком понятии как Dependency hell?
Просвещайтесь http://en.wikipedia.org/wiki/Dependency_hell
Вот до чего умничанье доводит.
> Вот же какой глупый Google, свой браузер Chrome поставляет ОДНИМ пакетом, где
> есть ВСЁ необходимое для работы.типичный подход авторов проприетарного софта. потому что пересобрать их софт под конкретную систему/дистрибутив невозможно.
ну и да: тот, кто ставит программы помимо официальных репозиториев дистрибутива, и при этом является чайником («обычным пользователем», ага) — вдобавок ещё и дебил.
>Вот же какой глупый Google, свой браузер Chrome поставляет ОДНИМ пакетом, где есть ВСЁ необходимое для работы.Поэтому при обновлении AdBlock или FlashPlugin надо опять скачивать весь браузер?
При этом, замечу, браузер штука вовсе не клиент-серверная — разбиения на отдельные пакеты там может быть меньше.
>А ещё слыхали о таком понятии как Dependency hell?
>Вот до чего умничанье доводит.А ты кроме wiki это где-нибудь видел, «не умничающий»? Если подобная проблема и возникает, то решается она удалением криво собранного непонятно кем пакета (который, как правило, не из официальной репы). Проблем с зависимости я за 10+ лет использования rpm-based дистрибутивов я наблюдал не так уж много,причём за исключение 1-2 случаев они были связаны с неправильной сборкой пакетов кем-то левым. И мне лично наличие зависимостей представляется штукой совсем неплохой, так как позволяет всю систему обновить, затратив куда меньше трафика, плюс централизованно обновлять компоненты системы, в которых разработчик что-то профиксил.
Да, вроде как достоинства, но есть и недостатки.Одно из основных отличий дистрибутивов - утилиты установки (еще репозитории и их наполнение/обновление, модель обновлений (rolling-release или нет), source-based/бинарные... вроде все основные отличия перечислил; ну, кроме документации). Если мы унифицируем этот момент, то дистрибутивы еще больше сближаются друг к другу. Мы идем к одном идеальному дистрибутиву?
> независимость от дистрибутива
Зачем? Универсальность? Неужели домохозяйка будет часто менять дистрибутивы? А опытный и так разберется, да еще и достоинства для себя найдет. Нам не нужен один универсальный дистрибутив, нам нужно разнообразие. Чтобы был выбор. Чтобы можно было заточить систему под себя. Да, есть свои недостатки - сложность. Но каждому свое. Хотите универсальный интерфейс установки - Windows, MacOS.
> а эта зараза в зависимостях тянет, кроме кодеков
Вот поэтому, я на source-based дистрибутиве - там большую часть ненужных зависимостей можно убрать.
Намёк: технические различия дистрибутивов - следствие, а не причина их существования. Причина - различия в идеологии.
> Причина - различия в идеологии.Можно пару примеров разницы идеологий? Желательно с их проявлениями?
> Можно пару примеров разницы идеологий?поставь бебиан. поставь слаку. если не прояснится — то увы.
Мда, как до конкретики доходит - сразу в кусты?
Rasch abkochen, dann Vormarsch nach Sokal.
> Можно пару примеров разницы идеологий?Одни считают что яйца надо чистить с острого конца. Другие с тупого. И что интересно, и тем и другим удобно именно так. Заставлять их насильно делать так как им не нравится - глупо.
> Одни считают что яйца надо чистить с острого конца. Другие с тупого.
> И что интересно, и тем и другим удобно именно так. Заставлять
> их насильно делать так как им не нравится - глупо.Абсолютно верно. Тут приходит третий и говорит: "Нет, я знаю как нужно! Нужно с середины!". Вот что делает сия утилита.
>> Причина - различия в идеологии.
> Можно пару примеров разницы идеологий? Желательно с их проявлениями?Например, в rpm установка пакетов в принципе неинтерактивна (хотя технически можно в %post сделать read, но librpm тогда за себя не отвечает), а сами пакеты имеют по дизайну жёсткие зависимости; всё это приводит к меньшей гибкости системы, но большей предсказуемости конечного результата в сравнении с dpkg или portage. Соответственно если потянуть в сторону гибкости -- получим снижение жёсткости/предсказуемости/воспроизводимости.
Можно стараться держать пакетную базу "на гребне волны", но там вместе со свежайшими фичами/фиксами плавают и свежайшие баги/разломы. Здесь в перетягивание каната играют новизна со стабильностью.
Есть и другие подобные выборы, которые приходится делать при определении дистрибутива; их набором дистрибутивы и отличаются по своей сути (сверх чего есть ещё различия реализации).
PS: скорее только не librpm, а то, что на ней дальше сидит (включая тот же synaptic).
> Например, в rpm установка пакетов в принципе неинтерактивна (хотя технически можно в
> %post сделать read, но librpm тогда за себя не отвечает), а
> сами пакеты имеют по дизайну жёсткие зависимости;В SUSE давным-давно Suggests есть. при том, что rpm у них самый что ни на есть апстримный, а не местечковый "4.0.4".
>> по дизайну
> SuggestsЧитай внимательней.
>>> по дизайну
>> Suggests
> Читай внимательней.Как "отдизайнишь", так и будет. Заюзаешь Suggests - получишь не-"жёсткие зависимости". Заюзаешь "rpm-4.0.4" - получишь... а хрен его знаешь, что получишь... заранее не угадаешь - он похерит зависимости, какие ты прописал и поставит свои, "жёсткие и единственно правильные":)
> Как "отдизайнишь", так и будет.Вот его и дизайнили под жёсткие -- насколько понимаю, ещё Eric Troan. Собственно, уточнить недолго.
> Мы
> идем к одном идеальному дистрибутиву?Не думаю. Вряд ли можно объеденить Gentoo, Arch и Ubuntu - у них совершенно разные цели, и очередная система установки пакетов этого не изменит.
>> Мы
>> идем к одном идеальному дистрибутиву?
> Не думаю. Вряд ли можно объеденить Gentoo, Arch и Ubuntu - у
> них совершенно разные цели, и очередная система установки пакетов этого не
> изменит.Совершенно верно. Так как сия тулза расчитывает одинаково работать в Gentoo, Arch и Ubuntu?
>Хотите универсальный интерфейс установки - Windows, MacOS.Шо? 0_0
>>Хотите универсальный интерфейс установки - Windows, MacOS.
> Шо? 0_0Руками.
> Шо? 0_0Скачал откуда-то, запустил exeшник (или msi), потом Next, Next, Next, Finish. 90% процентов народу так и делает.
Гному сейчас можно пожелать только одного - побыстрее натащить побольше дряни, сделать свой магазин приложений и отвалиться наконец от нормального линукса, как недавно сделал гномовский основатель Мигель.Тьфу. Была нормальная рабочая система. Чем дальше - тем хуже.
Пока что ты описал ubuntu с unity.
отчаянно реквестирую rhel 8 advanced gomne server
Гомнесервер. Звучит.
Речь идет о Гноме приложениях (расширениях - для начала), написанных на ЯваСкрипт! Подобные менеджеры есть и в Кедах и Цинамоне и пр... когда выбираешь тему оформления или нужное или ненужное расширение!!!
ЗЫЖ зачем перекручивать факты?! А вот Убунта с юнити, апстартом, миром, убунту-кэрнел и Убунту ОС, выпиливающая всяческие упоминания о Линукс и ассоциируя Линукс с Убунту - это Проблема.
>Речь идет о Гноме приложениях (расширениях - для начала), написанных на ЯваСкрипт! Подобные менеджеры есть и в Кедах и Цинамоне и пр... когда выбираешь тему оформления или нужное или ненужное расширение!!!Темы для qt/plasma/gtk2/gtk3, в том числе темы значков — всё это ставится из реп.
Там, где это делается иначе (виджеты для плазмы, темы для когтепочты) — оно жуть как неудобно.
> работая в роли надстройки над PackageKitПрослойка над прослойкой над прослойкой прослойки. Уважаемые гномеры, вы там что, долбанулись?
Что мы имеем сейчас: rpm(формат пакетов программного обеспечения)->rpm(программа, созданная для управления этими пакетами)->yum,apt-rpm,apt4rpm,smart,urpmi,zypper->PackageKit
К PackageKit присобачивается еще Listaller. Возникает вопрос - нужен ли PackageKit, Listaller и GNOME Software?Пакетами управляют либо мейнтейнеры, либо программисты(организации) создают свой пакет. Не проще ли, дабы не плодить сущностей, "разделить" работу таким образом: 1. мейнтейнеры создают свои родные для дистрибутива пакеты и функционала, заложенного в yum, для управления пакетами достаточно.
2. сторонние разработчики используют тот же 0install (Glick2) c ограниченным доступом к системе?
> Не проще ли, дабы не плодить сущностей, "разделить" работу таким образом:И тут — опа! — пакету, поставленному через 0install, требуется либа строго определённой версии, обновляемая yum`ом…
Единственное, для чего годится 0install — некритичные для системы пакеты вида «всё своё ношу с собой»: игры и т.п.
Такое часто можно просто в tar...
Либы с собой носить надо, их не так много.
Плохой подход? Посмотрите как игры в стиме бандлами идут.А по вашему как надо было? ставим игру и тут выскакивает диалог что надо еще в систему вкорячить десяток пакетов с вальв репы? )))
> А по вашему как надо было?а по нашему надо открывать исходники и пропихивать игру в репозитории популярных дистрибутивов. и тогда все надуманные проблемы, которые проприерасты сначала сами себе доблестно создают, а потом «решают» путём захламления чужих систем, просто не появляются.
