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

Кстати, вопрос в тему - допустим нужна инсталляция где системный слой и иксы - говно мамонта из CentOS или стабильного дебиана но чтобы с автоустановкой фиксов, а гном и вся гуйня - на уровне последней убунты. Это как-то на базе генты надо собирать?

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

Ага. Лучше будем рады кроличьему дерьму, которое нам дали - ведь главное, это что оно по форме чем-то напоминает пулю...


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

То есть открыть "Домашнюю папку" и распаковать в нее тарболл - требует копаться в FHS? А если на home у вас noexec, то во-первых вы уже копались в FHS или как минимум не брезгуете, а во-вторых ВНЕЗАПНО вам становится нужен рут для установки. Я, правда, не уверен, что бандлы сейчас умеют запрашивать рута для установки.


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

А в чем сакральный смысл обучения пользователей новому поведению, если они уже обучены не менее эргономичному поведению (дабл-клик требует меньше мышечной координации чем драг-н-дроп)?
В макос решили избавиться от концепции установки-удаления программ. С точки зрения юзабилити - это плюс, т.к. чем меньше пользователю нужно знать, тем проще система в плане освоения. Драг-н-дроп в папку Программы не является необходимым и, по сути, это то же самое, что перетащить документ в папку Документы. Здесь же пользователя не избавили от концепции установки программы - ему все-равно надо предварительно программу установить, перетащив ее на окошко ланчера. Вопрос: Зачем? Ответ: автор вдохновился драг-н-дропом.

>Если вы дебьяньшег у которого "все есть в дистре"
У меня в дистре не все есть. И я не против набрать временами
sudo mkdir /opt/program_name
cd /opt/mkdir/program_name
sudo tar -zxvf path_to_tarball

для того, чтобы поставить программу в /opt, или просто распаковать тарболл куда-нибудь в /home. Хотя конечно и можно было бы оформить это все покрасивее.


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

Их и бандл не решает. Не будет 10 версий гимпов на сайте гимпа как ни крути. Максимум будет одна версия. Так что в любом случае придется делать ./configure --prefix=$HOME/gimp_XXX для каждого.


>Так с чего вы взяли что его советники будут против решения "как в макос" ?

Потому что в макос не идеальное решение, а тут еще хуже. К тому же с ростом популярности убунты проблема того, что какой-то софт не работает на _их_ ОС, будет беспокоить каноникал только меньше, плюс к этому новел уже предлагает Build Service для всех основных дистрибутивов в мире линукса.


>А тогда таки что ви волнуетесь :)

Быдлодевелоперов не переношу.

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

>Олсо немного не понял. Чем не устраивают уже изобретенные способы управления?
Ну как? Там же drag'n'drop отсутствует.

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

Примерно так.

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

Или перепаковывать готовые бандлы для экзотики. Например готовый бандл - линукс 2005-2009 а нужно для 1999-2005 timeframe.

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

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

Бандл/тарболл это универсальная затычка тех мест где есть проблемы с апстримом . Которые никто решать не будет. Либо апстрим на это не расчитан. Ну не будет никто вам поддерживать чуть более устаревшее чем мейстрим. Даже за большие деньги. А бандлы/тарболлы это те же собственно ресурсы но немного переориентированные. Бинарные сборки и сейчас есть. Многие авторы их не делают исключительно потому что инфраструктуры нет. Нету аналога rpmbuild для бандлов вместе с толпами использующим и документацией.

Да и если у вас билды все равно делаются , можно поставить и пересборку для бандлов/тарболлы.

PS
Собственно ИМХО стандартный вариант использования это будет менее 5 бандлов/тарболлы, а остальной софт из дистрибутива.

Пример : Вы купили бинарную сборку(даже с исходниками) пакета X. Собрать его вы можете. Но там наложение кучи патчей, какие то правки и прочий гемор. Все это для использования пката в специальных use case.

Естественно автору сборки будет удобнее тупо залить ее в бандл. Так как для всех дистрибутивов и собирать один раз. Хотите пересобрать под ваш дистр - ловите исходниики. Только напильник в руки и неделю труда.

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

Вот вы и раскололись. Не батенька, вы именно это и утверждаете. Что репозитории решение неудобное. И даже вам неудобное. А вы им пользуетесь потому что терпите неудобство в обмен на правильность.

У вас как и многих тут латентные фошистские взгляды. Паладины такие, ДН&Дшные. Что мол надо всем в задницу вставить кол и чтобы ходили строем. Ненене. Вот с такой дисциплиной - вам к чорному влателину который будет говорить вам что делать.

Так вот. Репозитории решение УДОБНОЕ. Причем УДОБНЕЕ бинарных тарболлов. И решение настолько удобное, что коммерческие люди его в несовершенном виде уже скописпастили. См апп.сторе , steam , и так далее.

Для лемминга гораздо проще поставится один раз с диска, там прописываются автоматом все репозитории из сети, и все. Для стандартного западного случа always connected не хватает ТОЛЬКО ОДНОЙ ВЕЩИ. ИНТЕРФЕЙСА ДЛЯ ЛЕММИНГОВ. А так хочешь пакет - тыкаешь хочу, и все. Вообще думать не надо. Ткнул и работай.

ИЧСХ Тут пробегали сообщения что лемминг-интерфейс разрабатывают для убунты , да. И , бл.ть, те же лица, ТУПЫЕ ЗИЛОТЫ ЛИНУПСОИДЫ, срали в той ветки насчет того что кузнец не нужен. Ум демонстрировали, хехе. Тот же состав, те же парни.

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


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

Воот. Вместо того чтобы сделать МЕНЕЕ мозгозатратный способ, вы тратите усилия пытаясь ОСТАНОВИТЬ ПРОГРЕСС.

ИЧСХ сделать такоую вещь, визуальный интерфейс для леммингов просто. Но нет - предпочитаем боротся с "пороком" и "развратом".

> способ. Как Windows вытеснила нормальные системы, как
> WYSIWYG-редакторы вытеснили TeX.

Юзеры LyX смотрят на тебя как сам знаешь на что. Случай с техом как раз пример того как БЛАГОДАРЯ ТАКИМ КАК ТЫ ТеХ растерял позиции. Дело не в WYSIWYG самом по себе. Дело в упертых.

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

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

Как решал я. Ставил(копировал) свежий дистр в chroot (надо еще /proc смонтировать). там естественно настраивал yum. Ставил все нужные пакеты. Затем прописывал там в окружении путь к Xserver через DISPLAY. Все работало.
Чуть менее костыльно - делаем из chroot gdm,. настраиваем на твой X server. Тогда вообще все с виду хорошо. Но видео будет тормозить.
В теории помоему можно даже было сделать чтобы коннект шел через локальный x сокет. Тогда все без тормозов в принципе - локальное несетевое соединение.

Аналог(не пробовал) fakechroot . Та же федора ставится под юзером. Соотв дальше как и в предыдущем случае.

Оба варианта немного магии - а дальше ничего компилять не надо yum/apt и вперед.

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

> Ага. Лучше будем рады кроличьему дерьму, которое нам дали - ведь
> главное, это что оно по форме чем-то напоминает пулю...

Так не нравится - не пользуй. Но нет , надо махать флагом и клеймить неверных. Это концепт. "Может проехать 10 км а потом разваливается. Но зато на капле бензина, что внушает."

> То есть открыть "Домашнюю папку" и распаковать в нее тарболл -
> требует копаться в FHS?

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

> А если на home у вас noexec, то во-первых вы уже копались в FHS или

Если на home noexec - обращатся к тому кто его туда присобачил. Так как он знал что делал.
Естественно админ может ОТНЯТЬ возможность ставить свой софт. Админ же.

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

Тем что это два совершенно разных use-case.

> В макос решили избавиться от концепции установки-удаления программ.
> ...
> Вопрос: Зачем? Ответ: автор вдохновился драг-н-дропом.

Ну вот придут авторы бандла к Марку. Марк скажет то что вы сейчас говорите. Не вопрос скажут авторы - и сделают тоже самое на базе inotify.

Но я бы тут так не радовался - безопасность. Юзер сознательно кладет программу в папку приложений. Так что возможно Марку понравится как есть.

> для того, чтобы поставить программу в /opt, или просто распаковать
>тарболл куда-нибудь в /home. Хотя конечно и можно было бы оформить
>это все покрасивее.

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

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

> Их и бандл не решает. Не будет 10 версий гимпов на сайте гимпа как
> ни крути. Максимум будет одна версия.

Будет. Так как будут ранее собранные бандлы других версий. И также будут бандлы девелоперских версий.

> работает на _их_ ОС, будет беспокоить каноникал только меньше,

То есть из за тенденций убунту заховать мир :)

> плюс к этому новел уже предлагает Build Service для всех основных дистрибутивов в мире линукса.

Ага. Основных. Это будет отношение к девелоперам как у микрософта. "Мы главные , идите к новелю и компиляте там. Ну или валите."

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

> Быдлодевелоперов не переношу.

Так вы и смелых и решительно инновационных девелоперов не переносите :) Которые не боятся гнева хомячков и смело идут туда где не ступала нога линупсоидов.

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


>Тем что это два совершенно разных use-case.
То есть дабл-клик на *.parcel и последующая его установка невозможны в силу... эээ... чего?


>Я уже говорил - леммингам концепция файлухи неудобна, они пугаются и ниосиливают.
1. Лемминги - причина существования ботнетов.
2. Я ведь не против того, чтобы пакеты по двойному щелчку ставились и без рута. Я даже не против того, чтобы со временем эти же пакеты ставились через драг-н-дроп. Я против того, чтобы думать о драг-н-дроп, тогда как есть куча более важных проблем, которые нужно решить, чтобы девелоперы вообще хотели распространять софт независимо от дистрибутива и не в исходниках. Ну и сам подход к софту как "софт не нужно устанавливать" я считаю неправильным, потому что как признает и автор бындлов - никакой интеграции с системой нет. Пакетный менеджер дает ряд преимуществ перед подходом применяемым в OS X.


>Так вы и смелых и решительно инновационных девелоперов не переносите :)
Нет, это именно быдлоподелка, а не иновационное решение. Как иновационное решение советую посмотреть на то, что делает tinycore linux с пакетами.


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


Ладно, посмотрим через год на эту "инновацию".

>и всё, пакетный менеджер пал жертвой.

да не может он пасть жертвой. это слишком хорошая и вместе с тем простая вещь, чтобы пасть жертвой. провожу параллель - смотрим PC-BSD - система портов никуда ведь не делась, несмотря на всякие pbi.

>Базу для линукса нужно сделать общей и единой.. А тут уже даже в ядре разлад..

стандартизация нужна - кто ж спорит ? но беда в том, что её просто-напросто не будет. вот поэтому такое решение как Application Bundles - это ЖИЗНЕННАЯ необходимость. ну и пример типа 10 gimp-ов, разных версий, и надо написать/отладить плагин для каждого - ещё один пример в пользу Application Bundles.

О. Нашел наконец решение годовалой давности в духе сабжа. Правда тут к сожалению нет драг-н-дропа, но все же...

http://code.google.com/p/sfs-technology/

Очередной сумасшедший велосипед

А чтобы запускать ее из консоли - вписывать в PATH папки всех прог? Причем вручную, ведь заранее не известно, где и под каким именем она окажется. А если такая программа - либа, то и в LD_LIBRARY_PATH тоже? А бакап конфига системы как делать - etc-а нету. Бакапить все? А где man/info будет искать страницы документации? Или man-велосипед должен быть свой в каждой программе, как в винде? А как настраивать ассоциации для файлов - тоже вручную под каждое приложение? Обновлялку тоже свою в каждой проге писать? А logwatch, prelink?

Про автоматическое разрешение зависимостей тоже можно забыть (централизованного репозитория-то нет).

> * устанавливать новые версии без боязни конфликтов с предыдущими установленными версиями;

А если это была либа? Поставил новую, а используется старая? Получаем грабли с неработающими прогами из-за не той версии либ.

> быть уверенными в том, что ни один Bundle не сможет модифицировать ключевые библиотеки дистрибутива, пока вы сами не предоставите ему доступ для этого, с помощью пароля;

Но сможет испортить все остальные Bundle-ы. И запретить ему их портить не представляется возможным.

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

(Камень в огород гентушников со скриптами для сборки? В rpm/deb таких скриптов нет) Зато нужны нехилые скрипты для запуска каждого Bundle-а, ведь в них будет динамическое определение путей ко всем ресурсам и либам.

> * очень легко делиться программами с другими пользователями.

И пользователь получит ее с _моими_ настройками и логами. Как отделить их от программы?

Дистронезависимости и мобильности тоже не будет, либо придется включать в bundle все либы вплоть до glibc (для тех самых "старых дистрибутивов"), и калькулятор на GTK будет занимать 300МБ. Хотя и это не сработает - старый glibc loader не запустит новые бинарники.

Какие там еще плюсы остались? Установка нескольких версий? Это можно и проще сделать средствами rpm/deb. Все?

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

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

так и есть в ZeroInstall или nixpkg (дистр NixOS).

>delta-bundle

а кто будет эти бандлы делать? центральный deltup сервер, который постоянно будет загружен другими запросами? или что-то P2P-подобное? В NixOS есть нечто подобное. С виду, простой пакетный менеджер, с другим языком "ебилдов" -- настоящим функциональным языком, без побочных эффектов. То есть, можно *доказать*, что сборка по этому рецепту всегда приводит к одинаковому результату (с учётом разных версий toolchain gcc/binutils/ld/gold/prelink), расширить окружение, доказать что 2 рецепта с разным окружением приводят к одинаковому результату, и т.п. Если посмотреть вглубь, есть и адресация по уникальным хешам, несколько версий, описывающиеся функциональными зависимостями. Собранные бинарные пакеты nixpkg качает с фермы сборки, получается аналогичное buildbot или зачатки continuous integration. Насчёт дельт не помню, качается бинарный пакет целиком. К нему бы ещё транслятор прикрутить, ебилды в .nixpkg, и -- близкий к идеалу пакетный менеджер.