[ON] Online-каталоги универсальных приложений могут составить конкуренцию классическими репозиториями ПО

[t.t]

Да, у идеи магазина приложений много потенциальных дыр. Но без нее Linux не сделать популярной для дятлов. К сожалению. Тем более, в дистрибутивах типа MeeGo программы только через них и ставятся. Да и Центр приложений Ubuntu недалеко от этого ушел.

«Только через них» программы ставятся лишь в одном дистрибутиве на ядре Linux — в Android. Думаю, «дятлам» вполне хватит. А для людей есть все остальные дистрибутивы на выбор, лишённые не только этого, но и других серьёзных недостатков андроида.

[t.t]

дистрибутивные репозитории, и собственно создание дистрибутивов вокруг них привело к десятку крупных репозиториев и систем управления пакетами, и сотням более мелких. дальнейшее развитие привело к тому что каждый крупный репозиторий считает своим долгом пропатчить софт по своему усмотрению, и собрать с понравившимися параметрами. Развитие систем пакетного менджмента в принципе приводит к тому что сборка или пересборка пакета по своему усмотрению становится вуду. В свое время Daniel Robbins в туториале, кажется по башу, описал процесс написания простого ебилда, а через пару лет гентушники начали валить на Arch, потому что ебилды уже не были настолько простыми.

Возможно, такая проблема действительно существует. Решить её для себя можно переходом на «исходняковый» дистрибутив либо пересборкой отдельных пакетов. Предлагаемое в обсуждаемой статье это проблему не решит, а усугубит: вместо пакетов, собранных по усмотрению майнтейнеров одного дистрибутива (и протестированных на работу именно в этом дистрибутиве), будем иметь пакеты, собранные сотнями или тысячами авторов программ. Не говоря уж о том, что каждая программа будет тащить за собой все свои зависимости и в результате в системе будут появляться одни и те же библиотеки, собранные десятками разных способов. Работать вся эта каша будет даже менее надёжно и стабильно, чем винда: в винде ядро системы куда больше, т.е. простора для бардака несколько меньше; да и «дистрибутив» там один единственный.

[t.t]

ну вот как раз более-менее унифицированный способ запуска стороннего относительно дистрибутивных репозиториев ПО, мог бы быть неплохим костылем. В любом случае это в конечном счете игры в "yet another", как ни крути.

Это стороннее ПО тестировалось бы авторами пакетов на совместимость в лучшем с 3-5 самыми популярными дистрибутивами. В худшем — с одним: дистрибутивом автора (т.е. вообще случайным). В установке только из дистрибутивных репозиториев есть ещё один огромный плюс, помимо экономии ресурсов и лучшей совместной работы: если я какое-то ощутимое время использую дистрибутив, я знаю, насколько надёжны его репозитории (от «ничего не сломается» до безопасности системы). Про сборки авторов программ я не знаю ничего.

[.Serj.]

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

Portage SLOT же! Правда, насчёт разных префиксов не уверен…

[frp]

ну вот как раз более-менее унифицированный способ запуска стороннего относительно дистрибутивных репозиториев ПО, мог бы быть неплохим костылем.

Много кто предоставляет RPM-ки, которые теоретически можно ставить в любой дистрибутив. С deb-ами ситуация похожа (тем более, что ни один deb-based дистрибутив не ушел настолько далеко от debian, чтобы в него уже невозможно было бы ставить пакеты от debian).
А вообще бинарные пакеты - штука не кроссдистрибутивная по своей природе: у каждого дистрибутива в своей, особенной папке находятся скрипты инициализации (а некоторые вообще используют нетрадиционные системы инициализации), у каждого в своих папках конфиги, и другие различия, усложняющие создание кроссдистрибутивных бинарных пакетов.

[sash-kan]

ну вот как раз более-менее унифицированный способ запуска стороннего относительно дистрибутивных репозиториев ПО, мог бы быть неплохим костылем. В любом случае это в конечном счете игры в "yet another", как ни крути.

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

[Kisle_gliste]

А разве в MeeGo софт ставится как-то помимо Гаража? На любые командные строки с упоминанием yum идет ругань, а RPM ставить из консоли блондинко вряд ли будет.

[sash-kan]

diesel
как тебе эта новость в контексте нашего обсуждения?
[ON] Приложения, выпущенные под лицензией GPL, подлежат удалению из Apple's App Store

А разве в MeeGo софт ставится как-то помимо Гаража?

при чём тут какой-то гараж? из репозитория ставятся.

На любые командные строки с упоминанием yum идет ругань, а RPM ставить из консоли блондинко вряд ли будет

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

[diesel]

diesel
как тебе эта новость в контексте нашего обсуждения?
[ON] Приложения, выпущенные под лицензией GPL, подлежат удалению из Apple's App Store

в контексте этого обсуждения - никак, есть магазин приложений, есть приложение которое не соответствует требованиям, соответственно оно от туда вылетает. в истории с VLC в AppStore есть и несколько других интересных фактов: во-первых, в принципе, это приложение в AppStore могли и не пустить, потому как оно все-таки нарушает требование "приложения не должны клонировать функционал Apple-приложений", VLC этот функционал клонирует, правда не требует дополнительной конвертации видео. На проблему несовместимости лицензий обратили внимание фанатики, ну и собственно одним неплохим приложением в AppStore стало меньше, в итоге. Кстати, если верить новостям, недавно выходило обновление этого самого VLC под iOS, после которого он стал глючить и вылетать, и это само по себе вполне могло стать причиной непринятия приложения в AppStore, даже если бы не было конфликта лицензий. Но все это к текущему обсуждению отношения имеет очень мало

[Ism]

Кстати о проблемах совместимости
это что ? http://ru.wikipedia.org/wiki/Linux_Standard_Base

Чтоб все проги работали достаточно придерживаться этого стандарта

[t.t]

Кстати о проблемах совместимости
это что ? http://ru.wikipedia.org/wiki/Linux_Standard_Base

Чтоб все проги работали достаточно придерживаться этого стандарта

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

[frp]

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

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

[watashiwa_daredeska]

главный недостаток нынешних систем управления пакетами - невозможность ставить разные версии одного и того же пакета в разные префиксы.

Это могло бы быть недостатком систем управления пакетами, если бы… это поддерживалось самим софтом. Однако, префиксы задаются ещё при сборке, и просто поменять префиксы уже собранным бинарям — недостаточно, всё сломается. Иначе б уже давным давно сделали эту фичу.

[t.t]

главный недостаток нынешних систем управления пакетами - невозможность ставить разные версии одного и того же пакета в разные префиксы.

Это могло бы быть недостатком систем управления пакетами, если бы… это поддерживалось самим софтом. Однако, префиксы задаются ещё при сборке, и просто поменять префиксы уже собранным бинарям — недостаточно, всё сломается. Иначе б уже давным давно сделали эту фичу.

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

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

[watashiwa_daredeska]

Но это настолько редкий случай…

…что легче backports держать :)

[t.t]

Но это настолько редкий случай…

…что легче backports держать

Отож… (:

[frp]

Это могло бы быть недостатком систем управления пакетами, если бы… это поддерживалось самим софтом. Однако, префиксы задаются ещё при сборке, и просто поменять префиксы уже собранным бинарям — недостаточно, всё сломается.

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

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

Не все программы из дистрибутивных репозитариев. Некоторые программы слишком старые/слишком новые и их дистрибутивные версии не совместимы с нужными программе версиями. Раньше был в такой ситуации: есть KDE 3, который идет с дистрибутивом, и есть KDE 4, который нельзя поставить одновременно с KDE 3. А поставить нужно. Выходил из ситуации установкой из сорцов в /opt/kde4. Собирал несколько дней. (а с репозитариев при наличии возможности поставил бы за 10 минут).
А по какому поводу должно быть захламление системы разными версиями одних и тех же библиотек? Библиотеки, от которой ничего не зависит, aptitude по дефолту сносит автоматически (если они отмечены как установленные по зависимостям, а все библиотеки в нормальной системе должны быть установленными по зависимостям).

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

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

[watashiwa_daredeska]

Некоторые программы слишком старые/слишком новые и их дистрибутивные версии не совместимы с нужными программе версиями.

Даже если б можно было ставить по нескольку версий:
1. Кто будет держать в репозитории все версии всех пакетов за достаточно продолжительний промежуток времени? В Debian предыдущую-то не всегда можно скачать (по устаревшему Packages), ибо удалили уже.
2. Как держать метаинформацию? Packages Debian/sid/main уже сейчас 33M в распакованном виде, а если там ещё и по 20 предыдущих версий каждого пакета будет…
3. Префиксы/суффиксы — это хорошо, но не для библиотек. Ибо скачанная в бинарном виде софтина хочет все-таки /lib/libc.so, а не /lib/libc.so.other. Хотя для библиотек используются версионные симлинки и линковка со специфическими версиями. Т.е. не с /usr/lib/libsomething.so, а с /usr/lib/libsomething.so.X.Y.Z, но тогда при малейшем обновлении библиотеки потянется всё, что на ней держится.
4. Не все конфликты заключены лишь в версиях отдельных библиотек/бинарников, которых можно, при желании, наставить хоть 20 разных версий одновременно. Есть вещи, которые принципиально singleton'ы, и зависимости, в конце концов, в них таки упираются.

[t.t]

В мире Debian

Я немного в курсе. (: Debian использую примерно восемь лет на всех своих машинах.

Не все программы из дистрибутивных репозитариев. Некоторые программы слишком старые/слишком новые и их дистрибутивные версии не совместимы с нужными программе версиями.

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

Раньше был в такой ситуации: есть KDE 3, который идет с дистрибутивом, и есть KDE 4, который нельзя поставить одновременно с KDE 3. А поставить нужно. Выходил из ситуации установкой из сорцов в /opt/kde4. Собирал несколько дней. (а с репозитариев при наличии возможности поставил бы за 10 минут).

Так у вас такая задача и была: иметь одновременно две разные версии в одной системе? Это другой разговор. Но мне трудно представить, зачем это может быть нужно, кроме «посмотреть».

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

Если программа ставится не из дистрибутивных хранилищ, она почти наверняка будет зависеть не от тех версий библиотек, что уже стоят в дистрибутиве — и потянет их за собой. Если параллельно от этих же библиотек зависит что-то дистрибутивное, получим уже две разных версии. А если таких программ несколько — по одной дополнительной на программу. Достаточно общие вещи, вроде libc/libx11 или ncurses/gtk/qt, в таких случаях могут плодиться очень многократно.

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

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

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

[sash-kan]

А разве в MeeGo софт ставится как-то помимо Гаража?

при чём тут какой-то гараж? из репозитория ставятся.

встретив в pc magazine/russian edition за январь месяц упоминание про некий «гараж», из которого, якобы, и ставятся программы, аж заинтересовался, что ж это за гараж такой.
да, действительно, есть в разделе system tools иконка одноимённая.
при щелчке по которой гламурная такая программка запускается.

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

но ларчик просто открывался. это всего лишь огламуризированное средство установки/удаления 16 (как я насчитал) пакетов.
из репозитория, конечно, откуда ж вы думали?

[t.t]

А разве в MeeGo софт ставится как-то помимо Гаража?

при чём тут какой-то гараж? из репозитория ставятся.

встретив в pc magazine/russian edition за январь месяц упоминание про некий «гараж», из которого, якобы, и ставятся программы, аж заинтересовался, что ж это за гараж такой.
да, действительно, есть в разделе system tools иконка одноимённая.
при щелчке по которой гламурная такая программка запускается.

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

но ларчик просто открывался. это всего лишь огламуризированное средство установки/удаления 16 (как я насчитал) пакетов.
из репозитория, конечно, откуда ж вы думали?

Если я в своё время правильно понял, в maemo под «гаражом» понимается сайт для сообщества. Пакеты сообщества накапливаются в отделном репозитории, расположенном, насколько я понимаю, на garage.maemo.org. Ничего общего с «онлайн магазинами» весь этот проект не имеет в принципе. Подозреваю, что «гараж» для meego организован в точности так же.

[t.t]

Кстати, на сайте garage.meego.com обнаружил интересный анонс. Сейчас отдельной темой в новостях размещу.

[sash-kan]

Если я в своё время правильно понял, в maemo под «гаражом» понимается сайт для сообщества. Пакеты сообщества накапливаются в отделном репозитории, расположенном, насколько я понимаю, на garage.maemo.org. Ничего общего с «онлайн магазинами» весь этот проект не имеет в принципе.

maemo и её garage — это совершенно иная история.

Подозреваю, что «гараж» для meego организован в точности так же.

на данный момент это программа, с помощью которой можно установить или удалить «одним кликом» любой 16 отобранных миговцами пакетов из репозитория. там gimp, inkscape и т.п.
может быть потом будет как-то иначе.

[t.t]

Если я в своё время правильно понял, в maemo под «гаражом» понимается сайт для сообщества. Пакеты сообщества накапливаются в отделном репозитории, расположенном, насколько я понимаю, на garage.maemo.org. Ничего общего с «онлайн магазинами» весь этот проект не имеет в принципе.

maemo и её garage — это совершенно иная история.

Подозреваю, что «гараж» для meego организован в точности так же.

на данный момент это программа, с помощью которой можно установить или удалить «одним кликом» любой 16 отобранных миговцами пакетов из репозитория. там gimp, inkscape и т.п.
может быть потом будет как-то иначе.

Ну, поддомен garage.meego.com уже существует, но наполнения там пока нет (отображается в точности то же, что и на meego.org). Что уже говорит о том, что потом будет как-то иначе. Вот я и предположил, что будет примерно так же как в maemo: иначе зачем использовать в точности такие же имя проекта и расположение поддомена? Но ты прав: пока это не более чем моё предположение.