Универсальная пакетная система.

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

Ты только что описал ZeroInstall, ага.

Но при этом автоматом качается версию для дистрибутива, если есть, LSB версию если нет и автоматом ставит зависимости из репозитория. Даже если шарики в дистрибутиве называются колесики. Так как в .metapackage описано куда лезть за зависимостями для каждого конкретной версии конкретного дистрибутива. И библиотеки зависимостей, берутся из конкретного дистрибутива.

Ну вот зачем, зачем вам хочется всё централизовать. Уже есть централизованная система — это родная система пакетов дистрибутива. А с идеей «нажал на ссылку, поставилась программа», совершенно очевидно, что система должна быть децентрализованной, с резолвингом пакетов по URL.

Ты только что описал ZeroInstall, ага.

Если вырвать 2 предложения из контекста и опустить «незначительный» факт о том что zeroinstall и appstream это системы принципиально по разному решают принципиально разные проблемы, то да :D

Ну вот зачем, зачем вам хочется всё централизовать.

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

Уже есть централизованная система — это родная система пакетов дистрибутива.

Именно по этому ваш любимый ZeroInstall ее подменяет, в отличие от Appstream. Бхыхыхыхы.

А с идеей «нажал на ссылку, поставилась программа», совершенно
очевидно, что система должна быть децентрализованной, с
резолвингом пакетов по URL.

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

Если вырвать 2 предложения из контекста и опустить «незначительный» факт о том что zeroinstall и appstream это системы принципиально по разному решают принципиально разные проблемы, то да :D

Согласен. :-D

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

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

Именно по этому ваш любимый ZeroInstall ее подменяет, в отличие от Appstream. Бхыхыхыхы.

«Сморозил глупость, бхыхыхыхы».

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

apt. Видел как при установке пакета оно качало что нибудь со стороннего сайта (например при установке msttcorefonts) вгетом. Видимо используется preinstall скрипты внутри пакета.

В месте базы данных, по которой будет выполнятся поиск
соответствия пакетов в разных системах.

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

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

А там и не пакетная система описана в appstream, она в дистрибутивах остается без изменений. Интеграцию appstream обеспечивает дистрибутор, на той пакетной системе которой считает нужной.

Единый хомячковый гуй (или не гуй) функционально нельзя обеспечить без соответствующей поддержки. То есть единый гуй бессмыслен(ненужен...) без возможности сделать в нем «хочу шарики». И что бы поставились шарики, не важно называются они shariki-7876876675.mypackage , balls-7.8-i386.rpm или blz-client.deb + blz-server.deb. И да - совсем ненужен.

Опять же - единого хомячкового гуя может и не быть - это дело дистрибутора. Важно то что должно быть место где клиент наберет и/или поищет глазами привычное имя : скайп или там «шарики».

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

Это по сути вообще отдельная проблема, параллельная.

Во первых man rpm на тему --relocate . Эта проблема давно не на уровне пакетной системы а на уровне приложений. Приложения в среднем не поддерживают установку не в корень. Пакетной системе в принципе пофиг - ее можно сконфигурировать как угодно.

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

В третьих. Общих подходов для решения этой проблемы нормальным способом - не выработано. 0install это очередная попытка скрестить ужа с ежом используемая 3.5 анонимусами. Паралельно ей существует стопитсот других самопальных решений. Мне вот нравится как это в firefox сделано - никаких специальных команд, работает - и все.

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

«Сморозил глупость, бхыхыхыхы».

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

И да, конечно бывают ситуации когда библиотек в дистре нет, или они не той версии. Только вот если 0install пакет собирали не криворукие дебилы, он в плане стандартных библиотек ориентируется на LSB. А значит должен использовать пакетный манагер дистрибутива - а не лезть качать надцаную копию gtk.

А там и не пакетная система описана в appstream, она в дистрибутивах остается без изменений. Интеграцию appstream обеспечивает дистрибутор, на той пакетной системе которой считает нужной.

Единый хомячковый гуй (или не гуй) функционально нельзя обеспечить без соответствующей поддержки. То есть единый гуй бессмыслен(ненужен...) без возможности сделать в нем «хочу шарики». И что бы поставились шарики, не важно называются они shariki-7876876675.mypackage , balls-7.8-i386.rpm или blz-client.deb + blz-server.deb. И да - совсем ненужен.

Опять же - единого хомячкового гуя может и не быть - это дело дистрибутора. Важно то что должно быть место где клиент наберет и/или поищет глазами привычное имя : скайп или там «шарики».

После прочтения этих трех абзацев на моём мониторе появилась табличка «Монитор», на стуле — табличка «Стул», а на коте — «Кот». Кэп, перелогиньтесь, ваша аура вас выдаёт.

Это по сути вообще отдельная проблема, параллельная.

Вот её и обсудим. Гуй для установки шариков, как я уже говорил, вещь совершенно косметическая, и ничуть не интересен.

Во первых man rpm на тему --relocate .

Ну ты ведь понимаешь, что это совсем не то. Можно распаковать в недефолтный префикс какой-нибудь firefox. А с python такой номер не пройдёт, его просто нет смысла так ставить, если нет возможности питоноприложения автоматически сконфигурировать для его использования.

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

Это проблема, которая существует на уровне МЕЖДУ приложений (точнее, пакетов). Так что это уровень пакетной системы как раз.

Чтобы использовать программу, которая расположена по произвольному пути, надо решить 3 проблемы:

1. Программа должна поддерживать использование произвольного префикса, определяемого в run time, а не compile time.

2. Нужно ответить на вопрос: как программа узнает свой префикс.

3. Нужно ответить на вопрос: как программа узнает пути до своих зависимостей.

Первая проблема — это чисто технический момент. Патч, FR, коммит. Ничего интересного, опустим эти скучные детали.

Для второй проблемы POSIX не даёт нам ничего, но есть два костыля и 1 полукостыль. Первый костыль — это «смотрим в argv[0], если там есть слеши, то надеемся, что это наш настоящий путь, а если нет, материмся в stderr». Второй костыль — это /proc/self, который некросплатформеннен и которого может не быть. Третий вариант — это запуск первого варианта через #!/что-нибудь (/usr/bin/tclsh, например), что даст нам таки узнать путь.

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

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

Хотя меня мало заботят проблемы тёти Мани и её принципиальных (ли?) отличий от кулхацкерши Маньки, всё же замечу, что в этой самой винде поставить две программы разных версий — тривиальная задача для обычного пользователя. (Дуболомов, не знающих, с какой стороны тыкать в клавиатуру, не рассматриваем.) Так что не стоит недооценивать тётю Маню.

В третьих. Общих подходов для решения этой проблемы нормальным способом - не выработано. 0install это очередная попытка скрестить ужа с ежом используемая 3.5 анонимусами. Паралельно ей существует стопитсот других самопальных решений. Мне вот нравится как это в firefox сделано - никаких специальных команд, работает - и все.

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

Начать стоит с того, что осознать: сама постановка вопроса «как положить программу по произвольному пути, и чтобы она работала» не имеет решения в общем виде в силу своей бессмысленности. Ответственность за то, «чтоб она работала», несёт пакетный менеджер.

И как он это будет делать? Возможно 2 пути: либо мы конфигурируем пакет при установке, либо это происходит во время запуска. В первом случае мы в каталоге, где установлен пакет, размещаем либо соответствующие симлинки на его завимости, либо текстовые конфиги. Во втором случае... во втором случае можно придумать различные варианты, такие как «а давайте слинкуемся с библиотекой, которая скажет нам наши зависимости», и т.п., но по здравому размышлению становится понятно, что единственное годное решение это использовать промежуточный лаунчер.

Итак, нужен лаунчер, который разрешит зависимости, сформирует среду для запуска и запустит программу. Программа сможет легко найти свои зависимости по выставленным в лаунчере переменным окружения. При этом программа НИЧЕГО не знает, ни о лаунчере, ни о пакетном менеджере, не линкуется ни с какими «левыми» «библиотеками для поиска зависимостей» и т.п.

Сам лаунчер может быть вообще каким угодно и запускаться как угодно. Это может быть вручную набранная команда а-ля pkglaunch pkgname bin/somecommand. Или это может быть такая же команда из скрипта, автоматически помещенного в файл ~/bin/somecommand при установке пакета. Или это может быть вообще прямой запуск /somepath/somecommand, превращенный хуком в libc в запуск лаунчера на основании того, что /somepath ведет в глубины каталога ~./.local/packages. И даже такой вариант: если у меня нет в системе этого pkglaunch, я просто могу вручную выставить переменные среды и запустить программу.

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

Итак, установив таким образом несколько пакетов и начав пользоваться ими, в определенный момент мы зададимся вопросом наподобие следующего: «Ага, вот этот пакет настроен использовать lib-some-library версии 1.0.0, а я хочу проверить его работу и с улучшенной lib-some-library 1.0.10-mycustompatches. Как это сделать удобно?». Можно переконфигурировать установленный пакет, сделать свои дела, а потом по необходимости переконфигурировать обратно. А можно... Можно в этот момент понять, что раз уж за запуск полностью отвечает лаунчер, читающий конфигурацию пакета из собственной базы данных, то «приложением» служит уже не программа в пакете, а конфиг, запускающий эту программу... [В этом месте я задолбался писать, так что мысль останется неоконченной, по думаю, понятно, куда я клоню.]

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

Таки отличается. Во-первых надо уточнить сразу, что zeroinstall даёт возможность указывать собственные реализации для url. Так что не проблема сказать ему «вот локальная реализация, её и юзай». При этом зависимости вида gawk>=someversion и вовсе можно резолвить просто проверяя наличие оного gawk в PATH и спрашивая версию непосредственно у него же. Но это не главное. Главное, что ты не с того конца смотришь на вопрос, отсюда и проблемы. Давай я сначалп приведу такой пример:

Вот у Ruby есть собственная система пакетов. Пользователь может ставить gem-пакеты в свой $HOME без проблем. Другое дело, если админ хочет поставить общесистемный пакет. Он, конечно, может таки при помощи gem поставить этот чертов пакет и развести срач в /usr, потому что часть файлов будет управляться одним пакетным менеджером, а часть — другим. Как поставить пакет правильно? Нужно воспользоваться пакетным менеджером дистрибутива. Но поскольку в репах дистрибутива может не найтись нужного gem-пакета, то возникает идея: а давайте сделаем мост gem-deb (или gem-rpm, gem-pacman и т.п., в зависимости от системы). Индекс gem-репоритория конвертируется в индекс deb-репозитоория, устанавливаемый gem-пакет конвертируется в deb-пакет, который устанавливается штатными средствами.

С zero install то же самое. Пакеты zeroinstall можно налету конвертировать в формат пакетов дистрибутива и устанавливать. При этом установленный этим образом пакет по-прежнему остаётся zeroinstall-пакетом.

Уточню мысль. «можно налету конвертировать» — в смысле не прямо щас можно, а концептуально можно, если задаться целью реализовать это.

Вот её и обсудим.

А вот это интересно только 2.5 анонимусам. Ваш капитан очевидность.

Гуй для установки шариков, как я уже говорил, вещь совершенно
косметическая, и ничуть не интересен.

Это он вам неинтересен. Всем остальным интересен. Именно система для установки шариков интересна (гуй у нее действительно вторичен). Потому что, как это всегда в жизни бывает, сделать нечто для массового хомячка гораздо сложнее чем для 2.5 задротов.

Более того, если этот «гуй» в правильном виде появится, как это предполагается с поддержкой 3rd party приложений, то и указанную тобой проблему будет гораздо понятней как решать. Потому что тот же appstream задает фреймворк для решения подобной проблемы.

Ну ты ведь понимаешь, что это совсем не то. Можно
распаковать в недефолтный префикс какой-нибудь firefox.
А с python такой номер не пройдёт, его просто нет смысла так
ставить, если нет возможности питоноприложения
автоматически сконфигурировать для его использования.

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

Это проблема, которая существует на уровне МЕЖДУ приложений (точнее,
пакетов). Так что это уровень пакетной системы как раз.

Неа. Не все проблемы «между пакетов» должен и будет решать пакетный манагер. Если вам упал пакет для арча а у вас федора, то он не поставится. И эту проблему пакетный манагер (rpm+yum, условно) решать в принципе не будет. (alien это не решение, есличо, так как зависимости)

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

Задача манагера пакетов разрешать зависимости в пределах своего дерева и в пределах той инсталляции за которую он отвечает. И весь / это одна инсталляция - дистр линукса. А вот 0install и/или ~/opt/mozilla_from_tgz это другие инсталляции с другими пакетными манагерами.

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

И принципы разрешения зависимостей будут разные. Так что ваша постановка вопроса принципиально неверна.

Хотя меня мало заботят проблемы тёти Мани и её
принципиальных (ли?) отличий от кулхацкерши Маньки

А зря. Потому что мы пляшем от потребностей конченого пользователя. Которые выражаются в том что юзер хочет «шарики» и получает шарики. А не парит мозг «под капотом» дистрибутива на тему того как тут поставить шарики и почему они тут называются гиперкубики(потому что так правильно1111 это гиперкубики111).

И как только вы начинаете плясать от пользователя вы видите что 0install и ваш подход к вопросу это «еще один пакетный манагер» и много срачей на тему того что «0install лучше111». А не решение проблемы.

А вот appstream это следующий шаг к решению. В том числе и к решению проблем кулхацкерши маньки.

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

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

В порядке креатива можно предположить что будет существовать дерево, а то и сеть (много родителей) из пакетных деревьев. Где в самом верху будет пакетное дерево дистрибутива, а внизу пакетное дерево каких нибудь плагинов к фаерфоксу, которые цепляются за фаерфок поставленный в пакетное дерево 0install'а(например). И все это будет интегрироватся через систему вроде .desktop файлов, стандарты на взаимодействие леса пакетных деревьев с «главной кнопкой» - главным меню, рабочим столом а так же с кнопкой «хочу шарики».

Таки отличается. Во-первых надо уточнить сразу, что
zeroinstall даёт возможность указывать собственные реализации для url

«ваша постановка вопроса принципиально неверна.» ... А именно вы пытаетесь решить проблему взаимодействия между деревьями пакетов путем выдумывания еще одного пакетного манагера, зато «гениального». Который будет вовсюда лазать и там своими грязными ручонками лапать. Ставить gem в дистрибутив и тп. Но будет сверхгибкий и сверхещезнает что еще.

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

И начинать надо с простых но нужных кейсов, а не со сложных, опасных и ненужных. А вы начинаете расписывать юзкейс когда gem лезет в парент своими грязными руками создавая пакеты простым конвертером, но нифига не понимая что паренту надо, и какие там могут быть еще косяки. Это disaster, waiting to happen.

Я считаю что максимум на начальном уровне нужно стандартизированное взаимодействие по принципу PackageKit... при чем с конкуренцией стандартов. То есть вежливо попросить парента поставить пакет.... при одобрении пользователя. Остальное по факту НАХ*Й не нужно и может быть реализовано теми особенными извращенцами кому это очень надо. А вот *ОЧЕНЬ* нужен какой то механизм, на уровне дизайн-идей, как разрешать зависимости по родительским деревьям, которое может быть не одно. В результате получается что в пакетную систему нужно добавлять концепцию плагинов для разрешения зависимостей из родительских пакетных деревьев.... и в сущности все(все что касается именно пакетных систем)

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

И appstream как раз эту сложную проблему решает, хотя бы частично, для случая простых юзерских приложений.