Application Bundles - новый путь для дистрибьюции программного обеспечения в Linux

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

А зачем мне писать "мой линукс" ? У меня уже есть линукс. Там уже все есть и было задолго до того как молодежь вроде тебя добралась до моего ЛОРа.

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

И никого не волнует ТВОЯ система. Так как свободный линукс для свободных людей. Хотим что бы пакет был интегрирован в дистрибутив - делаем то же самое что и сейчас. Текущие решения решают все ТВОИ проблемы. Но не все проблемы реально существующие у разных пользователей линукса.

> Подход разделяемых библиотек должен быть повсеместным, обязательным
...
> Такова природа вещей, и есть только один способ исправить -- _заставлять_ делать по-своему.


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

> Нет ничего хуже ad hoc решений,

Хуже временных решений только отсутствующие решения.

> от них нужно избавляться. И если сегодня в ультимативном порядке не _заставить_ программистов писать без привязки к конкретной версии библиотеки, всеобщее счастья с, цитирую: "Централизованное обновление же библиотек" никогда не наступит.

Воот. "Заставить, заставить". Спроси саныча, он тебе порекомендует пристойный сайт с садомазо. Найдешь там себе госпожу, и канализируешь свои сексуальные потребности. И придешь на ЛОР безо всякого этого "того заставить, этого заставить"


> Нужно предоставлять такие пакеты в формате популярных пакетных менеджеров. Направить усилия на их стандартизацию.

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

> когда есть доступ к исходникам. Я знаю, что говорю, ибо сам работаю в науке.

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

> Стыдливо засунули свои школьные мечты на третье место. Вот истинная причина -- не хватает игр. Нафиг-нафиг.

фейспалп жпг

Решение должно быть ориентировано не на линупсоидов, а на существующие проблемы. Эта проблема - распостранение third party applications.

> В ОСС мире нет ни одной причины сидеть на старом дистрибутиве. Жизнь портят бинарные закрытые блобы.

Все с вами ясно. Молодой человек, приходите лет через 10-15. Поумнеете , будет о чем с вами поговорить.

> Если пакету нужна библиотека, то какая разница, притащить ее вместе

Потому что если стоить 10 пакетов гимп в базе и зависимости становятся запутанными и много лишнего в основной системе.
Инсталляция указанным методом это другой подход для ДРУГИХ задач. Естественно юным линупсоидам внутренне непонятным

> Пожалуйста, реализуйте что-то типа слотов в gentoo на уровне пакетного менеджера. Это будет лучшее применения вашей школьной энергии.

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

> По отдельности слова понятны, но что имел в виду автор? svn?

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

> Ответ на два пункта выше -- сделайте оверлеи типа как в генту.

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

> Итого, в сухом остатке: юношей с горящими глазами пороть, а после

Вы гентушник и этим все сказано. В школу, разочаровыватся в генту и ставить виндовс, как это бывает с 99 % гентушников. Ждем Дарт-анонимуса который расписываети нам прелести виндовса через пару лет.

PS
И в pmn встроена поддержка инсталляции на пользовательском уровне, хехе. OO так инсталляется. Матчасть то учи, пригодится.

PPS
И ты демонстрируешь фундаментальное непонимание вообще зачем такие решения нужны. И нежэелание понять. Вакхабит, хуле.

>Вот истинная причина -- не хватает игр.

Халява, порно и игры - вот рецепты успеха любой, не только компьютерной, технологии. Первое и второе в линуксе есть, проблемы с третьим.

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

Блин. Апокалиптика какая то. Меньше на ночь читайте фантастики с плохим концом.

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

ПМ и тарболл это подходы к проблеме инсталляции софта с РАЗНЫХ концов. Ну вот сейчас у нас засилье ПМ. Убило это тарболлы ? НЕТ. Они нестандартизированные и неудобные, но коммерческий софт и приспособленый для этого FOSS их использует. И засилье новой инкарнации тарболлов не убьет ПМ. Так как ПМ решает те задачи которые тарболлы не решают плохо.

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

Тарболлы же идут от *софта* . Решение для ISV, third party. На уровне которого есть много разных дистрибутивов и приходится жертвовать одними в пользу других. И как только мы хотим перестать жертвовать - мы приходим к тем же решениям что и в тарболле. Получается что в результате например делаем не rpm 4 redhat, а rpm для rpm-based. Что опять же приводит к тому что распакованный rpm запускается везде.

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

> И в pmn встроена поддержка инсталляции на пользовательском уровне, хехе. OO так инсталляется. Матчасть то учи, пригодится.

Не знаю, что такое pmn.

> И ты демонстрируешь фундаментальное непонимание вообще зачем такие решения нужны. И нежэелание понять. Вакхабит, хуле.

Не лезь в мой уютненький линукс. Сиди на своей винде/макос. И да, я вахабит, нет, даже хуже. Я буду защищать тот линукс, который меня устраивает и который мне нравится.

> До тех пор, пока мне не расскажут, как в этом случае патчить дыру в какой-нибудь часто используемой библиотеке (qt, например) - я отказываюсь обсуждать это серьезно.

Элементарно, Ватсон. Включить в предлагаемый стандарт Application Bundles автоапдейт, при чем пригодный для запуска в бекграунде. Как это собственно делает фаерфокс. Тут как раз новый алгоритм для бинарных дельт подоспел. Соотвественно раз они все равно регистряются изнутри в соотв конфигах, то можно от админа запускать sudo -u pupkin update_all_app_bundles

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

> Не знаю, что такое pmn.

Мистайп. rpm

> Не лезь в мой уютненький линукс. Сиди на своей винде/макос. И да, я вахабит, нет, даже хуже.

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

> Я буду защищать тот линукс, который меня устраивает и который мне нравится.

Дружок, я исключительно на линуксе с тех пор как ты пешком под стол ходил. И меня давно уже достали все новые и новые толпы "линупсоидов нового поколения". Которые набижали, учат меня как жить, и обьявляют линукс "своим линупсом". Он такой же ваш как и мой. Точнее он такой же мой как и ваш.

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

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

> Дружок, я исключительно на линуксе с тех пор как ты пешком под стол ходил. И меня давно уже достали все новые и новые толпы "линупсоидов нового поколения". Которые набижали, учат меня как жить, и обьявляют линукс "своим линупсом". Он такой же ваш как и мой. Точнее он такой же мой как и ваш.

Дружок, мне под 30 если что. И я твердо знаю, что если допустить сюда идиотов, они захватят все.

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

Повторюсь: я не против ревизии/развития способов установки программ. Но следует

а) Четко поставить цели, которые достигаются тем или иным приемом. Дать use case для них.

б) Указать, какой ценой достигаются эти цели

в) Оценить риски(!) принятия того или иного способа решения

г) Оценить перстективы развития и гибкость предлагаемых решений.

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

Все use case'ы, которые указаны авторами в качестве преимуществ системы бандлов можно сделать на уровне пакетного менеджера. Но нет, блядь, мы изобретем собственную, кривую, косую и несовместимую с ничем систему.

Ах да, последнее.

Я в курсе про --relocate как способ поставить пакет. Проблем в том, что слишком многие помечены как NON RELOCATABLE

>созданное за 5 минут на коленке решение неграмотных школьников, не знакомых с понятиями "инженерия" и "стратегия развития".

Какая "инженерия" и "стратегия развития" не должна позволять запустить GIMP 2.6.7 на RHEL?

> Дружок, мне под 30 если что.

А что ведешь себя как малолетний фанатик ?

> И я твердо знаю, что если допустить сюда идиотов, они захватят все.

И опять всплывает старая проблема, нужны ли идиоты в линуксе. Нужны. Так как массовость. Линукс он для всех, а не для очередной илиты.

> Эти бандлы, повторю еще раз -- созданное за 5 минут на коленке решение неграмотных школьников, не знакомых с понятиями "инженерия" и "стратегия развития".

Эти бандлы ничем принципиально не отличаются от бинарных тарболлов, каковые были есть и будут. Попытка развить тему. Сделать их более юзер френдли. А получилось не очень хорошо - так тема трудная.

У этого решения есть много недостатков, но и фиг с ним. Не приживется - так умрет. Главное что есть движение в нужном направлении. App bundle базируется на плечах гигантов. В том числе и на инфраструктуре типа LD_LIBRARY_PATH которую сделали во многом специально для таких решений.

И "линукс" простепенно двигается чтобы решать указанные проблемы не путем приспособления неприспособленых для этого решений типа ПМ, а путем создания решений хороших и приспособленых. Возможно и с интеграцией с ПМ. Только вот не привязанных к ПМ а именно что опционально интегрированных.

> Видимо, дедуль, ты тоже того... не вышел у родителей, раз возраст пришел, а ума нет.

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

А что, сборку из сорцов уже злые RHEL'щики отменили? Ужас! Немедленно продайте RHEL обратно и купите win2008

> Вот теперь ты обвинил инженеров ISV которые используют подобные решения спокон веков

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

>А что, сборку из сорцов уже злые RHEL'щики отменили? Ужас! Немедленно продайте RHEL обратно и купите win2008

Насколько я понял там пересобрать надо все начиная от GTK. В сети были выложены конструкции шаманских бубнов для того чтобы водрузить GIMP 2.4 взамен дистрибутивного 2.2.*, но меня они почему-то не воодушевили.

> А что ведешь себя как малолетний фанатик ?

Я не фанатик, а человек, защищающий работоспособность _моего_ инструмента. Он сначала мой, а потом уже твой и школьника Леши. Я, знаешь ли, кровно заинтересован в том, чтобы не получить вторую винду ил макос со всеми ее недостатками. Просто потому, что если мне нужна винда/макос я иду и ее покупаю, мне не нужна "бесплатная винда", мне нужно нечто лучше ее.

> Насколько я понял там пересобрать надо все начиная от GTK. В сети были выложены конструкции шаманских бубнов для того чтобы водрузить GIMP 2.4 взамен дистрибутивного 2.2.*, но меня они почему-то не воодушевили.

Т.е. ты думаешь, что кто-то готов для тебя лично сделать такую сборку -- пересобрать GTK и проч. и проч. только ради того, чтобы ты смог "заценить"? Интересный подход. Ты хотя бы заплатишь за работу?

Кроме того, если бы авторам GIMP было бы интересна платформа RHEL, они бы могли сами статически все собрать и запаковать в rpm. Но, видимо, это им не нужно. И непонятно как наличие бандлов помогло бы им осознать эту нужность.

> Пока бындлы -- это отличный пример того, как НЕ НАДО делать:
> фактически хоронить систему разделяемых библиотек, наносить удар по
> безопасности, т.к. обновление общего кода бандлом слишком
> трудозатратно, поощрение бинарного блоба и многое другое.

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

Систему разделяемых библиотек никто не хоронит. Ее использование
ставится в зависимость от задачть АВТОРА сборки. Как это всегда и было. Никто не мешал тебе таскать в своем rpm свои версии библиотек и хоронить мечту svu об обновлениях на корню.
Удар по безопасности никто не наносит так как ситуация НЕ ИЗМЕНЯЕТСЯ. Юзеры еще sunos обюожают рассказыват как они засирали свой хомяк сборками gnutools, де факто делая ту же дыру в безопасности, но РЕШАЯ ТУ ЖЕ ПРОБЛЕМУ.


> Все use case'ы, которые указаны авторами в качестве преимуществ
>системы бандлов можно сделать на уровне пакетного менеджера. Но нет,
>блядь, мы изобретем собственную, кривую, косую и несовместимую с
>ничем систему.

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

Вот я поставил себе десять гимпов в хомяк с целью отладки плагина. Мне наплевать в этом случае на обновление libz ! Пусть она будет хоть полностью дырявая. А вот где я найду десять пакетов разных гимпов(нужной версии) НЕ КОНФЛИКТУЮЩИХ ДРУГ С ДРУГОМ ? А если они еще и девелоперские. rpm это не магия ! Кто нибудь покопался в хедерах и у меня битая база пакетов на машине. А если там еще rm -fr какаято_директория под рутом? И я не про хацкеров, я про м...ков - пакеты то неотлаженные, но дистрибутивные.

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

>Т.е. ты думаешь, что кто-то готов для тебя лично сделать такую сборку -- пересобрать GTK и проч. и проч. только ради того, чтобы ты смог "заценить"? Интересный подход.

Программы обычно апдейтят если нужны фичи которых в старых версиях нет.

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

> Кроме того, если бы авторам GIMP было бы интересна платформа RHEL,
>они бы могли сами статически все собрать и запаковать в rpm. Но,
>видимо, это им не нужно. И непонятно как наличие бандлов помогло бы им
> осознать эту нужность.

Так весь смысл в том что если бы гимп компилили еще и в тарболлы-бандлы, хоть авторы хоть "проект gimp.bundle.org" , можно было бы просто скачать бандл и поставить на любой линукс более менее разумной давности !!! Бандлы же для ВСЕХ дистрибутивов - в этом его смысл. Мы покупаем за место потраченное на библиотеки, которые мы таскаем с собой, универсальность.

> Т.е. ты думаешь, что кто-то готов для тебя лично сделать такую сборку

Весь смысл в том что они и так делают разные сборки. А идея в том чтобы они делали сборки немного другого формата, универсальные сборки. И таким образом решая не проблему лично Абсурда, а проблемы все пользователей кто НЕ МОЖЕТ скачать ЭТОТ гимп из дистрибутивного репозитория. А таких много. И для некоторых версий гимпа ОЧЕНЬ много.

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

>Неубедительно ...
>Превращать в бардак deb-дистры - очень сомнительно, что на это
>поведется сообщество.

у меня ощущение что app bundle это такая злая магическая сила ВНЕЗАПНО превращающая в бардак даже инсталляции дебияна защищенные по уровню A+ . То есть винчестеры лежащие в сейфе.

серьезная угроза, да ;)

>Вот я поставил себе десять гимпов в хомяк с целью отладки плагина

Есть более жесткий сценарий - допустим, все дистрибутивы начиная от Hardy/fc8 тихо виснут на твоем железе и поэтому желания обновляться нет никакого. Желания сидеть и локализовывать этот баг - тоже.

> злая магическая сила ВНЕЗАПНО превращающая в бардак

:)))

Это максимум трепа на пару дней.

> Есть более жесткий сценарий - допустим, все дистрибутивы начиная от
> Hardy/fc8 тихо виснут на твоем железе и поэтому желания обновляться
> нет никакого. Желания сидеть и локализовывать этот баг - тоже

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

PS
Упоминать не стал - а то школие эрегируется, начнет кричать про "обновления", и потеряет над собой всяческий контроль.

Хм для игр вполне неплохо! для узкого круга софта тоже, но для большинства нет... Базу для линукса нужно сделать общей и единой.. А тут уже даже в ядре разлад..(не говорю про узкоспециализированные ядра там оно действительно нужно)

Хотя конечно этот бундл недотягивает до "идеального" решения.

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

Чего нет:

* что бы на любом линуксе(разумной устарелости) можно было unpack&run
Как сейчас:
** надо поставить запускальник
** он работает через гуй.
** запаковано lzma. То есть обычным tar с bz2/gz не распаковать.

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

* нужен набор утилит типа automake. Которые будут генерить скрипты для бинарного тарболла-бундла. В которых и будет магия(см магия.) Также там будут всякие конфигуряторы, хелпы, конфиги для библиотек включаемых в тарболл, описания известных зависимостей и др.
Идея в том чтобы любой разработчик приложения мог поставив этот набор утилит собрать тарболл/бундл быстро и без лишних трудов.

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

магия стандартных скриптов( аналог firefox который пускает firefox.bin):
* должны уметь определять наличие необходимых версий либ локально и подменять ими то что идет в тарболе, через настройку preload пути.
* настраивать preload, пути и прочие необходимые программе вещи, описанные в "как создать бундл".
* должны уметь регистрироватся в конфигах ${HOME}/.app_bundle даже без наличия инсталлятора в системе. Тогда последущие утилиты смогут найти инсталлированные программы.
* делать какие то вещи в зависимости от системных и пользовательских настроек. Например прописыватся в ${HOME} базу rpm используя rpm --justdb
* запускать в зависимости от конфигов пользовавателя какие то pre-start скрипты прописанные в дистрибутиве и аналогичными пакетами: это для расширений.
* иметь хуки для апдейтеров. Апдейтеры могут быть как запакованы в бундл, так и доставлятсмя отдельно в ~/ или в систему.

* держать несколько уровней инсталляции: В хомяк, не от рута но в директорию общую для нескольких пользователей, от рута в какую либо директорию(системная инсталляция)

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

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

PS
Вроде все написал, но скорее всего что то важное забыл.

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

>Включить в предлагаемый стандарт Application Bundles автоапдейт, при чем пригодный для запуска в бекграунде. Как это собственно делает фаерфокс. Тут как раз новый алгоритм для бинарных дельт подоспел. Соотвественно раз они все равно регистряются изнутри в соотв конфигах, то можно от админа запускать sudo -u pupkin update_all_app_bundles

Т.е. а) убить основную идею этих самых бандлов "каждая программа несёт с собой библиотеки ТЕХ САМЫХ ВЕРСИЙ, с которыми была собрана"; и б) получить ещё один менеджер пакетов, но "более другой" :)

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

>Мы Вашего мнения не спрашиваем, девушка.
А что о себе во множественном числе? Сиамские близнецы?

Да здравствуют антивирусы для линуха!

Не сойдет. Чтобы собрать бандл, надо перекомпилировать софт из исходника, с применением спциально бубна под названием apgcc

>А я буду использовать бинарные тарболлы, которые уже есть, которые постепенно добьют до нужного уровня возможностей.
Зачем нужны AppBundles, если уже есть бинарные тарболы? Потому что в бандлах есть запускалка для домохозяек и потому что установка состоит из перетаскивания бандла на эту запускалку вместо обыкновенного распаковывания его куда нужно? Механизм интеграции в ОСь отсутствует, механизм проверки есть ли нужная либа в дистрибутиве отсутствует. И прежде, чем вы возразите, что нужные либы уже находятся в бандле, подумайте кто их туда засунет и как этот человек определит, что они там нужны. Настоящих проблем бандлы _не_решают_

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

Так и скажи: "Разработчики - дебилы, один я умный и знаю Как Надо Делать Правильно".

> Т.е. а) убить основную идею этих самых бандлов "каждая программа
> несёт с собой библиотеки ТЕХ САМЫХ ВЕРСИЙ, с которыми была собрана";
> и б) получить ещё один менеджер пакетов, но "более другой" :)

Ты не понял. Разработчик бандла кладет в апдейты те библиотеки что считает нужными. И точно так же можен включить дельту к бинарю. А может и не включать если при пересборке с пропатчанной либой бинарь не меняется(за исключением таймстампов).

И почему бы ему не включить более другой менеджер пакетов ? Даже как бы никто не мешает класть в бандл rpm'ки и систему работы со своим мини репозиторием.
Обьяснить почему это нормально или сам догадаешся ?

> Не сойдет. Чтобы собрать бандл, надо перекомпилировать софт из исходника, с применением спциально бубна под названием apgcc

Ну-с... тогда... увы и ах! :)

> Зачем нужны AppBundles, если уже есть бинарные тарболы?

А бандлы это и есть бинарные тарболлы. Только названные по другому :p

> Потому что в
>бандлах есть запускалка для домохозяек и потому что установка состоит
>из перетаскивания бандла на эту запускалку вместо обыкновенного
>распаковывания его куда нужно?

Да. Но я совершенно не отрицаю что бандлы это всего лишь следующий небольшой шаг в нужном направлении :)

> Механизм интеграции в ОСь отсутствует, механизм проверки есть ли нужная либа в дистрибутиве отсутствует. И прежде, чем вы возразите, что нужные либы уже находятся в бандле, подумайте кто их туда засунет и как этот человек определит, что они там нужны.

Это проблема АВТОРА бандла. Так как универсального решения тут нет. Хотя в некоторых случаях можно будет ориентироваться на LSB (сюрприз)

> Настоящих проблем бандлы _не_решают_

Они решают некое небольшое их множество. Тут так все и делается, в линуксе. Бандлы будут заниматся проблемой на уровне ГУИ+домохозяка и приучения хомячков(и разгневанных хомячков) к данной технологии. agcc и прочие аналогичные прокты на уровне программиста. LSB на уровне наличия стандарта, что бы бандл не таскал с собой лиших библиотек.

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

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

А вот тут я жестоко рассмеюсь вам в лицо :) Так как пока конечно бандлы это не то. Но настоящим "бандлам из преисподней"(тм) поддержка авторов дистрибутивов, и даже админов, совершенно не нужна, МВАХАХАХАА ! Так же как она не нужна обычным бинарным тарболлам :)

А потом дистрибьюторы будут ВЫНУЖДЕНЫ добавить эту штуку. Так как Марк со своей Бубнтой ее точно добавят. А при ее стандартизации на уровне fd.org ее добавить и в ГНОМ.

PS
Вам не остановить "тарболлы ктулху"(тм). Они придут и заховают ваш уютненький дистрибутивчик. Столетиями они дремали, спрятавшись в глубоко в океанах линукса,в фаерфоксе и опенофисе. Но когда звезды займут правильное положение, они восстанут из своей подводной могилы, вернутся, и научат линуксоидов новым способам радоватся и инсталлировать приложения.

Разработчики бандлов дебилы. А умный, как показывают комментарии на ЛОРе, не я один.

>Это проблема АВТОРА бандла.
Совершенно верно. И эта проблема является более важной чем установка через drag&drop.

>Бандлы будут заниматся проблемой на уровне ГУИ+домохозяка и приучения хомячков(и разгневанных хомячков) к данной технологии.
Что проще: залезть в пакетный менеджер, ввести описание программы которая нужна, выбрать программу которую хочешь установить или залезть в гугл, среди кучи не относящихся к делу страниц найти нужную программу, скачать ее и попытаться установить?

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

>agcc и прочие аналогичные прокты на уровне программиста.
Агцц не должен быть нужен вообще.

>LSB на уровне наличия стандарта, что бы бандл не таскал с собой лиших библиотек
И как человеку определить каким версиям стандарта соответствует бандл и его дистрибутив?

>Так как Марк со своей Бубнтой ее точно добавят.
Учитывая что Марк не единолично, отрезая обратную связь, принимает решения очень маловероятно. Только если эти бандлы допилят так чтобы решить проблемы связанные с тарболами. Судя по тому, что приоритетом оказалось "сделать, чтоб как в макос" - это вряд ли случится.

> Совершенно верно. И эта проблема является более важной чем установка
> через drag&drop.

А еще более важной является проблема голода на земле. Давайте не будем требовать серебряных пуль пусть даже и в отдельной области.

Приучить простых пользователей "сувать parcel в окошко x" это титаническая проблема сама по себе. И я как раз про то, что умные сами разберутся, как они это делают и сейчас.

А стандарт на уровне десктопа - открыть папку "Приложения" закинуть в нее парсел как в макос, радоватся, вполне себе нормален. Не копаясь в FHS как это требует обычный бинарный тарбол.

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

Какой вы все таки трудный. Если вы дебьяньшег у которого "все есть в дистре", и вы можете просто залезть в инсталлятор дистрибутива, и вам этого достаточно, таки уйдите из треда. Данная фигня не для вас :)

Помним что если у вас и так все есть - так и не надо тут ничего ломать.

И ксате юз кейсы тестера и девелопера плагина, которые я привел, дебьян не решает.

> Это шаг в ненужном направлении, ибо решаются либо мелкие и ничего не
> значащие проблемы, либо уже решаемые другими проектами.

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

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

> Проблемы, которые в действительности стоят на пути унифицированного
> способа распространения программ для линуха не решаются.

Это дает фреймворк, некие рамки, что бы их решать. Если рамки будут плохие - ну выкинем.

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

> Агцц не должен быть нужен вообще.

Ага. Тоже изобретаем вундервафли в подвале ? apgcc это враппер, то есть набор настроек :p А набор настроек нужен потому что линукс совершенствуется и дефолтные настроки - использовать "последнее". Так что функционально он будет нужен либо так либо иначе. Для того чтобы от него избавится придется много менять там где это неоправданно экономически.

> И как человеку определить каким версиям стандарта соответствует
> бандл и его дистрибутив?

Например так: Пакетик кулпрог-21 для этого, этого, этого. Пакетик кулпрог-22 для этого и этого. По описанию на сайте.

Или по некоему коду в названии файла как сейчас в rpm. Или в хедерах.

> Учитывая что Марк не единолично, отрезая обратную связь, принимает
> решения очень маловероятно.

Так с чего вы взяли что его советники будут против решения "как в макос" ? Почему собственно ? Это будет только если они эксперты с ЛОРа.

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

А тогда таки что ви волнуетесь :) Путь FOSS - релиз ерли, релиз офтен.
Шоу ми зе коде, как говаривал Линус.

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

> Какой вы все таки трудный. Если вы дебьяньшег у которого "все есть в дистре", и вы можете просто залезть в инсталлятор дистрибутива, и вам этого достаточно, таки уйдите из треда. Данная фигня не для вас :)

Помним что если у вас и так все есть - так и не надо тут ничего ломать.


А_а, так это вся маета по трудостройству rpm & Ко костылей значит ?
Ну-с, подождем пока это все само отомрет, ковульсии роста забавны
и родовые травмы при создании всяких караоки-дистров приводят или агрессивному самообрезанию и "это не надо" (слакоподобные дистры) или назойливому переизобретению apt под разными названиями и соусами.

>Разработчик бандла кладет в апдейты те библиотеки что считает нужными.

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

> А_а, так это вся маета по трудостройству rpm & Ко костылей значит ?

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

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

> Ну-с, подождем пока это все само отомрет, ковульсии роста забавны
>и родовые травмы при создании всяких караоки-дистров приводят или
>агрессивному самообрезанию и "это не надо" (слакоподобные дистры) или
>назойливому переизобретению apt под разными названиями и соусами.

Если бы апт был бы таким идеалом даже yum бы не понадобился.

> Разработчики бандлов дебилы. А умный, как показывают комментарии на ЛОРе, не я один.

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

Бред. Виндовс-вей не нужен. Устанавливать приложения из папок, хранить для каждой проги свои библиотеки... Это обычно в венде такой способ используется, а в большинстве линух-дистров уже давно придумали более продвинутые системы управления установленным софтом. Возвращаемся в прошлое, да еще и в виндовс-вэйное >__<

Олсо немного не понял. Чем не устраивают уже изобретенные способы управления? Качнул бинарники+ресурсы софтины в тар.гз, установил через пакетный менеджер нужные библиотеки, ???, профит. Подходит для всех дистров и никаких бандлов. В общем я думаю этот способ подходит только для "софта на флешке", да и то можно было придумать что-нибудь попродуманнее, например хранить библиотеки в отдельной директории чтоб не дублировались.

> Качнул бинарники+ресурсы софтины в тар.гз, установил через пакетный менеджер нужные библиотеки, ???, профит

да-да все пользователи должны разбираться в "нужных библиотеках" и уметь вручную их ставить :) тут обычный deb - самое оно, но deb требует прав root, а такой Bundle пользователь может запустить со своего хомяка - что таки более секурно

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

Нет. Это как раз удобное и правильное решение. Но удобное для знающего человека. Это вам не мышкой в setup ткнуть, тут думать надо. Последнее как раз удобнее для лемминга (ничего же учить не надо, можно не думать, процедура наглядная), но плохое для системы в целом. Однако, коммерческие дистрибутивы вынуждены заботится о массовости распространения (чего можно достигнуть в том числе потакая желаниям леммингов). Поэтому есть риск, что сей порочный способ инсталляции программ сначала станет популярным, потом войдет в стандарт, и наконец вытеснит более совершенный (но и более мозгозатратный) способ. Как Windows вытеснила нормальные системы, как WYSIWYG-редакторы вытеснили TeX.

>Если бы апт был бы таким идеалом даже yum бы не понадобился.

<troll_mode>То-то я смотрю: apt для rpm-ов сделали, а вот yum для deb-ов что-то не спешат. Может, он просто нафиг никому не сдался? ;)</troll_mode>

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

"Для всех остальных" существует такая вещь, как OBS, где я, к примеру, собираю дебы шести разных видов (при том, что "вживую" у меня есть только 2 из них), а ещё один очень хороший человек собирает кучу rpm-ов (при том, что самому ему нужен только один - для Федоры). Делается это "лёгким движением руки" без каких-либо напрягов: залил сорцы/спек/dsc для дебианов - подождал пару часов/чуть больше (зависит от загруженности OBS в данный момент) - получил готовые пакеты подо всё, что шевелится.

А будет ли нормально работать OBS, если программа использует библиотеки, которых нет в репозиториях дистрибутивов?

Нет, OBS конечно хорошая штука, но всё равно не серебряная пуля.