Представлен (http://lists.freedesktop.org/archives/distributions/2012-Oct...) релиз AppStream-Core 0.1 (http://www.freedesktop.org/software/appstream/), первого компонента проекта AppStream (http://distributions.freedesktop.org/wiki/AppStream), в рамках которого развивается единый API, формат для обмена мета-данными и интерфейс для универсального управления установкой программ в различных дистрибутивах Linux. Проект развивается на нейтральной площадке сообщества FreeDesktop при участии представителей дистрибутивов Fedora, Ubuntu, Debian, openSUSE и Mageia.
AppStream-Core предоставляет средства для работы с базой данных с информацией о пакетах, доступ к которой организован через API на базе GObject. Указанный API позиционируется для упрощения создания универсальных центров установки приложений и каталогов программ, способных работать в различных дистрибутивах. AppStream-Core планируется задействовать в Ubuntu Software Center и GNOME Software.<center><a href="http://gitorious.org/appstream/resources/blobs/raw/master/ar... src="http://www.opennet.me/opennews/pics_base/0_1349332830.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
AppStream является клиент-серверной системой, определяющей общие способы обеспечения сбора информации о пакетах и состоящей (http://distributions.freedesktop.org/wiki/AppStream/Implemen...) из четырех базовых частей: клиента, зеркала мета-данных, сервера-компоновщика и сервера для обеспечения социальной активности (обсуждение, голосование). Вместо формирования супер-пакетов, которые можно установить в любом дистрибутиве, планируется сформировать обобщенный индекс мета-данных (http://distributions.freedesktop.org/wiki/AppStream/Metadata...), ссылающийся на различные репозитории и источники пакетов. Мета-данные будут храниться на отдельном сервере, накапливающем информацию о доступных пакетах, типах доступных репозиторев и местах фактического размещения пакетов. Cервер-компоновщик занимается извлечением информации о пакетах из .desktop-файлов, которые формируются создателями дистрибутивов для каждого пакета, и формированием результирующих XML-индексов ("appdata.xml"). Непосредственная установка программ будет осуществляться при посредничестве системы PackageKit (http://www.packagekit.org/), которая будет привлекать штатные средства каждого из дистрибутивов (yum, apt, conary, box, alpm, smart, pisi, zypp и т.д.). Поддержка ведения рейтинга пакетов и организации их обсуждения будет реализована через задействование внешних OCS-серверов (http://www.freedesktop.org/wiki/Specifications/open-collabor...) (Open Collaboration Services).
URL: http://lists.freedesktop.org/archives/distributions/2012-Oct...
Новость: http://www.opennet.me/opennews/art.shtml?num=35000
А потом Google за'opensource'ит Chrome Store. :)
Т.е. визуально это практически тоже, что и в Google Play. Открываешь PackageKit, а там под софтом плюсики и коменты. Или еще что-то есть?
"Я сам писателя Пастернака не читал", но, насколько я понимаю полёт мысли авторов, они пытаются обойти неприятности в инсталляции программного обеспечения в Linux, связанные с обилием пакетных менеджеров и версий библиотек.
Но не созданием "одного большого универсального пакета", а хранением неких метаданных о пакете и сборкой .deb/.rpm/.tgz/.моя-супер-хрень "на лету".Ну и ещё таки да, плюсики и каменты. Каменты же жгут... ;)
Это где это Вы про "сборку на лету" увидели-то?
Сборку пакетов, очевидно.
Девелоперу придется делать свою софтину под все версии задействованных либ и еще и тестировать работу, а потом оформлять все это правильно, заливать в данную систему, которая потом соберет пакет из нужных бинарей под конкретную версию конкретного дистра? Или я не читатель?
> под все версии задействованных либОбычно указывается "версия X и новее". И авторы либ кроме совсем уж раздолбаев не ломают обратную совместимость там и тут, понимая что иначе их либу все станут старательно избегать.
> Девелоперу придется делать свою софтину под все версии задействованных либБольшинство скорее всего будет собирать только под один-два любимых дистра. Скорее даже под один. %)
make
> makeНичего не меняет.
А оно будет считать конфликтные файлы, линки? Это что-же я поставлю на бубен пкет с федоро-репозитроия, оно мне все зафелит, затрет мои кошерные либы своими корявыми...
Танцы с бубном обеспечены, шаманы вышли с отпуска.
Аноним не читатель, аноним писатель?
Так оно будет хронить сорцы и компилироваться на стороне сервера имея один репозиторий для всех дистрибутивов или как ? Если нет, то в чем фишка ?
Вообще похоже на "давайте слабаем один универсальный стандарт, который покроет остальные 7...".
Но я всеми лапами За.
"Теперь в мире 15 соревнующихся между собой стандартов".
Значит, не забросили, пилят неспеша. Это хорошо.
Это, случайно, не для того, чтобы дать Valve единый механизм распространения игр одинаково на все дистрибутивы?
Этот проект начался за пару лет до анонса Steam для GNU/Linux.
"Теперь и майонез!" - Valve работает, значит, надо разработку форсировать и предложить.
Как в Valve то теперь вцепились, не оторвать. И к месту и не к месту. Посмотрим, на сколько на самом деле дури хватит у Valve. *потирая ручонки и мерзко хихикая
вместо единого стандарта распространения (и автоматической компиляции "на местах") исходников и бинарников устраивающего всех он пилят индекс сайтов разработчиков ??? ну что ж за бред :(((
а-ха (долго смеялся)
> вместо единого стандарта распространения (и автоматической компиляции "на местах") исходниковГентушники негодуют? Хинт: для сборки например разлапистой игры надо 100500 хидеров и объектников библиотек. Они прилично весят и для всех кроме разработчиков являются балластом в системе.
Ubuntu станет ещё лучше с этой штукой
Разочаровали. Зачем плодить кучу реп для каждого дистра? И держать зоопарк форматов пакетов, а также пакетных менеджеров? Один формат пакетов, один формат метаданных, один набор реп для всех дистрибутивов, и набор рейтингов и комментариев. Один багтрекер и общие сопровождающие пакетов. Плюс возможность создания репы для каждого дистра с специфичными для данного дистра версиями ПО. И только пакеты из таких дистроспецифичных реп(вроде репы с Unity для Ubuntu) должны поддерживаться разработчиками дистра. А общие для дистров пакеты должны поддерживаться разработчиками данных пакетов для всех дистров. Плюс набор рецептов(типа PKGBUILD для построения кастомным пакетов) и пользовательских реп, куда закачав рецепты, можно получить пакеты(и поделиться ими с ближними своими, как этому учит Библия и Столлман). Тогда все дистры станут унифицированными, и все различия сведутся к набору предустановленного по умолчанию ПО, да выбору версии данного ПО из имеющихся версий в репах(stable, testing, unstable etc.)
> Разочаровали. Зачем плодить кучу реп для каждого дистра? И держать зоопарк форматов
> пакетов, а также пакетных менеджеров? Один формат пакетов, один формат метаданных,
> один набор реп для всех дистрибутивов, и набор рейтингов и комментариев.
> Один багтрекер и общие сопровождающие пакетов.Что с tradeoff'ами делаем -- или кто не в ногу, тех в расход?
> Что с tradeoff'ами делаем -- или кто не в ногу, тех в
> расход?Зачем же так? Просто оптимальный набор пакетов(так сказать рекомендуемый базовый набор) продвигать и популяризировать для всех дистров. А кто не в ногу шагает, пускай поддерживает отдельную репу... Зато и в данной ситуации есть свой плюс - нестандартная репа будет доступна всем дистрам. А это значит, что пользователь Fedora сможет юзать Unity даже в том случае, если везде и всем будут настойчиво рекомендовать выбирать Gnome или KDE. В целом(надеюсь) платформа будет все всё теснее интегрироваться, и рано или поздно станет стандартом де-факто. При правильном подборе основных компонентов платформы 90% пользователей основных дистров даже не будут стараться их заменить на что-то альтернативное. А для любителей экспериментального ПО, всяких новых или очень старых версии ПО и различной экзотики можно будет создать отдельные репы(но общие для всех дистров).
> А кто не в ногу шагает, пускай поддерживает отдельную репу...Так разница порой в самых глубинных, базовых вещах. Например, должен ли пакетный менеджер уметь интерактивную установку или можно полагаться на то, что если запустил его -- то при отсутствии форс-мажоров когда-то да вернёт управление. Или в ядро включать фирмварь (поработоспособнее), или нет (погнутее). Причём последний вопрос проще, ядер-то хоть можно несколько держать.
> Зато и в данной ситуации есть свой плюс - нестандартная репа будет доступна всем дистрам.
> А это значит, что пользователь Fedora сможет юзать Unity даже в том случае,
> если везде и всем будут настойчиво рекомендовать выбирать Gnome или KDE.А вот и нет, если в федоре не согласятся уродовать всё подряд под Unity.
Разумный баланс есть и сейчас дистрибутивы явно от него далеки, но описываемое -- просто другая крайность, даже если не брать в расчёт плодящих форки бездумно.
