LINUX.ORG.RU

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

 ,


0

0

В силу нарастающих тенденций к будущему оформлению приложений в виде неких контейнеров предлагаю обсудить тему правильной доставки софта в мире Linux.

  1. Весь софт под контролем ЦПМ + единичные сторонние программы допустимы в /home или др. местах вне системной иерархии 238 (30%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Весь софт под контролем ЦПМ + единичные сторонние программы допустимы в /opt или др. местах в системной иерархии 205 (26%)

    ***********************************************************************************************************************************************************************************************************************************************************************************

  3. Абсолютно весь софт должен быть под контролем централизованного пакетного менеджера (ЦПМ) 179 (22%)

    ************************************************************************************************************************************************************************************************************************************************

  4. Оставить под контроль ЦПМ базовую систему, остальное вынести в отдельные пакеты, использующие функции ЦПМ (напр. установку зависимостей) и системную иерархию 43 (5%)

    *********************************************************

  5. ЦПМ - зло, я хочу всю систему в виде самодостаточных бандлов-контейнеров 33 (4%)

    ********************************************

  6. Оставить под контроль ЦПМ базовую систему, остальное вынести в самодостаточные бандлы-контейнеры вне системной иерархии (напр. /home) 31 (4%)

    *****************************************

  7. Свой вариант 23 (3%)

    ******************************

  8. Оставить под контроль ЦПМ базовую систему, остальное вынести в отдельные пакеты, использующие функции ЦПМ (напр. установку зависимостей) и оверлейные ФС 16 (2%)

    *********************

  9. Оставить под контроль ЦПМ базовую систему, остальное вынести в самодостаточные бандлы-контейнеры в системной иерархии 14 (2%)

    ******************

  10. Оставить под контроль ЦПМ базовую систему, остальное вынести в самодостаточные бандлы-контейнеры в слоях оверлейных ФС 14 (2%)

    ******************

Всего голосов: 796



Проверено: beastie ()

Оставить под контроль ЦПМ базовую систему, остальное вынести в самодостаточные бандлы-контейнеры вне системной иерархии (напр. /home)

Reset ★★★★★
()

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

handbrake ★★★
()
Ответ на: комментарий от matumba

ЦПМ - зло
Gobo-linux - вот путь настоящего юникса!

Вы являетесь пользователем этого дистрибутива?

Essentuki_17 ★★
()

Абсолютно весь софт должен быть под контролем централизованного пакетного менеджера (ЦПМ)

Пусть проприетарщина ставится в /opt, но через ЦПМ, как хромы и иже с ними...

Самописные скрипто- и самосборные бинарные говна в /home только на компах разработчиков и серверах, где обычный пользователь чётко знает, зачем ему это. На обычных десктопах хомячков - /home с noexec+quota (дабы рут мог починить сдохшее).

Опрос - говно, так как способы доставки ПО для сервера web-приложений, ведроида Васи Пупкина, и его же рачедесктопа таки отличаются.

dhameoelin ★★★★★
()

базовая система (включая стандартные компоненты навроде de и браузера) из пакетного менеджера, остальное самодостаточными контейнерами в /opt (system-wide) или в $HOME/.local. При этом абсолютно не важно, будут ли они контролироваться ПМ, потому что они не должны выходить за пределы своей директории и их удаление будет выполняться простым удалением одной единственной директории.

Ах да, запускатор еще надо в /usr/local/bin или $HOME/.local/bin для сохранения совместимости

arcanis ★★★★
()
Последнее исправление: arcanis (всего исправлений: 1)
Ответ на: комментарий от arcanis

Достаточно важно, будет это контролироваться ПМ или нет. Тут либо тебе сделали так, что оно само поставится, создаст симлинки в /usr/local/bin, будет обновляться и потом полностью и корректно удалится (в идеале). А если нет, значит разработчик програмы положил на вас болт и предлагает всё делать руками и через Ж.

kirill_rrr ★★★★★
()

Оставить под контроль ЦПМ базовую систему, остальное вынести в самодостаточные бандлы-контейнеры в слоях оверлейных ФС

Почему так мало голосующих за этот максимально разумный компромисс? Лучше конечно как в Mac OS X, только чтоб из консоли такие бандлы ставились в том числе, поверх некоей базовой системыю

I-Love-Microsoft ★★★★★
()

Абсолютно весь софт должен быть под контролем централизованного пакетного менеджера (ЦПМ)

Неконтролируемые помойки типа Program Files (x86) не нужны. Проприетарщина обычно ставится через самодельные инсталляторы, которые нужно выпиливать, опакечивать только полезный контент и ставить его через ЦПМ. В пакет также можно включить дополнительные файлы/шкрипты для более тесной интеграции в систему, например *.desktop файлы или *.service для systemd. Пример - dropbox в раче, делающий все вышеперечисленное.

archie
()
Ответ на: комментарий от kirill_rrr

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

arcanis ★★★★
()

Слишком много вариантов для выбора ответа, до конца дочитал с трудом.

EvAn
()

Где вариант «не понял вопроса»?

ashot ★★★★
()

Устал читать все варианты

disee ★★★
()
Ответ на: комментарий от kirill_rrr

Мы о разных вещах тогда говорим =)

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

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

arcanis ★★★★
()
Последнее исправление: arcanis (всего исправлений: 1)

Свой вариант

Слишком много букв и вариантов. Я за тоталитаризм.

WARNING ★★★★
()

По-моему идеальный вариант установки пользовательских приложений сделан в OS X. Когда у тебя независимые бандлы в хомяках лежат. И нет никакого геморроя с зависимостями.

Zetoke
()
Ответ на: комментарий от arcanis

А действительно ли такой геморрой поддержка актуальной сборки под ещё один дистрибутив? Я знаю работу с пакетным менеджером на уровне плинтуса, ещё хуже понимаю как собираются программы. Тем не менее у меня одно время были скрипты, собирающие и обновляющие новые версии wine, firefox'a, thunderbird'a и ядра.

Встроенная система самообновления? Почему бы не проверять новую версию, а если она есть, то запрашивать у пользователя права (gksu или как то так), скачивать и ставить всё тот же пакет? Разве это сложнее чем поддержка инсталятора внутри самого приложения?

kirill_rrr ★★★★★
()

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

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

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

Deleted
()

Я хочу систему в которой все под контролем ЦПМ. И всякие /usr/bin убрать. Только /bin /etc /home /mount и т.д. только хард кор :)

EmgrtE ★★★★
()

Про Program Files уже была шутка?

fbiagent ★★★
()
Ответ на: комментарий от kirill_rrr

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

Права спрашивать, конечно, хорошо, но слишком много параноиков. Да и я скайпу какому нить не особо доверю рутовые права. Оптимальное решение - API для проверки версии и опциональное окошко-уведомление на старте с предложением перейти на сайт.

arcanis ★★★★
()

В идеале, конечно, всё должно быть через ЦПМ, но идеал недостижим, так что проголосовал за ЦПМ+единичные сторонние в /home и др (ибо желательно иметь возможность ставить софт пер юзер, /opt для этого не подходит).

redgremlin ★★★★★
()

ничего не понял

zgen ★★★★★
()

В пользовательской системе хочу бандлы, чтобы свежий софт ставить от производителя. В серверной системе хочу ЦПМ и только ЦПМ.

Если бы ещё эти бандлы обновления безопасности сами ставили, было бы совсем хорошо.

Aceler ★★★★★
()

ЛОРосрач объявляю открытым! :-)

Michail_Ul ★★
()

Единичные в /home RLY?

А монтировать хомяк (и прочую «внесистемщину») только с noexec,nosuid уже не считается нормой? Или как дистрибутив при установке авторазметкой наколбасил, так в fstab никто и не заглядывает?

oddmean
()
Ответ на: комментарий от arcanis

Ну, тогда есть сложный вариант. В ПМ надо прикрутить какой нибудь api для отдельной кучи сторонних реп (чтобы не гадить в портедж, sources.list или ещё куда) и пусть сторонние пакеты передают туда строчку, откуда их обновлять. А дальше всё стандартно: руки, хрон, нужные права без передачи рутовых прав скайпу.

Потом сам скайп может скачать файл и вызвать что то по типу sudo apt-get install /tmp/skype-999.deb, прав он при этом не получит.

Другое дело, что прога может быть недоверенной и её охота установить в $HOME или какой то контейнер. Как тут правильнее не знаю, но делать всё это каждый раз руками в случайные места точно не правильно.

kirill_rrr ★★★★★
()

Все, что ставится ЦПМ — ставить ЦПМ. Кое что ставится в /opt (интеловский компилятор, например). Ну так и пусть будет в опте. Ну и кое что, что собирается руками,  — в /usr/local или в /usr/local/<prefix>, если оно большое и make deinstall плохо за собой убирает.

Как-то так.

gns ★★★★★
()

неких контейнеров

ретроградов слышу я

autonomous ★★★★★
()

Я голосовал за второй пункт, но на самом деле предпояитаю смесь первого и второго пункта

slapin ★★★★★
()

Весь софт должен быть под контролем централизованного пакетного менеджера, только менеджер должен быть более развитым и позволять без свистоплясок ставить по нескольку версий программ.
То есть именно ЦПМ в случае чего должен организовать бандл и положить туда нужные для приложения версии либ. Только так можно будет спастить от яндекс-баров, ящитаю.

ss_ash ★★★
()
Ответ на: комментарий от arcanis

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

В идеальном мире-то конечно.

special-k ★★★
()
Ответ на: комментарий от archie

Неконтролируемые помойки типа Program Files (x86) не нужны. Проприетарщина обычно ставится через самодельные инсталляторы, которые нужно выпиливать, опакечивать только полезный контент и ставить его через ЦПМ.

Зависимости, зависимости, зависимости, зависимости, поняха.

special-k ★★★
()

Непонятный опрос. Предпочтительно конечно абсолютно всё под контролем ЦПМ, а вот в жизни приходится мирится и с opt и с home. Ответил первый вариант, т.к. предпочтительно было бы так.

Еще не понятно куда Steam(который ставит игры мимо ЦПМ) относить. К варианту с home?

Loki13 ★★★★★
()
Ответ на: комментарий от special-k

если разработчикам бить обухом по пальцам, то рано или поздно мир станет если не идеальным, то хоть немного лучше

arcanis ★★★★
()
Ответ на: комментарий от special-k

Зависимости, зависимости, зависимости, зависимости, поняха.

Какие такие зависимости? Проприетарные пакеты должны таскать все используемые либы с собой и не иметь дополнительных внешних зависимостей. Речь о том, что если проприетарщик не соглашается любезно предоставить правильный пакет для ЦПМ, а вместо этого дает самодельный кусок блобятины, то его нужно раздербанить, перепаковать в православный пакетный формат, опционально доложить туда своих либ/служебных файлов/скриптов и ставить все это через ЦПМ. Проще говоря - сделать репак.

archie
()
Ответ на: комментарий от Alyssa

В QNX из пакетов распаковываются «бандлы» в пакетную файловую систему. А ядро предоставляет приложениям UNIX-представление этой файловой системы. Что-то аналогичное предлагает GoboLinux, но там это костыли над древней и вонючей как Г. мамонта Unix-структурой, а в QNX всё нативно и корни растут из пакетной ФС, а не наоборот.

DRVTiny ★★★★★
()
Ответ на: комментарий от archie

то его нужно раздербанить, перепаковать

Тем и заняты. Вышел релиз 1000000 человекочасов, что поменялось - ничего не поменялось (кроме версий пакетов), и так 20 лет подряд, дербанят, дербанят...

special-k ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.