Как отметили другие в комментариях, очевидная причина, по которой требуются права доступа root, заключается в том, что предварительно собранные пакеты устанавливаются в общие системные каталоги, которые не должны быть доступны для записи любому пользователю. Почему не «другой пользователь без полномочий root»? Я бы сказал, потому что достаточно пакетов, чтобы внести изменения в общие системные файлы и каталоги, так что не стоит усложнять отслеживание того, какие пакеты действительно нуждаются в руте, а какие нет, а также потому, что не установка как root не купит вас так много - вы уже доверяете поставщику многих основных пакетов, и еще несколько. Но в конечном итоге, да, компромисс между безопасностью и производителями, похоже, решил, что здесь простота выигрывает.
Это приводит нас к вопросу о том, почему пакеты нельзя просто установить, скажем, в домашний каталог пользователя. На самом деле, во многих случаях, они могут, но только если вы используете исходный дистрибутив, такой как Gentoo. В этом случае вы просто компилируете программу с соответствующим --prefix или аналогичным (многие, но не все части программного обеспечения поддерживают такую концепцию). Однако большинство дистрибутивов основаны на двоичном коде, и в этом случае проблема заключается в том, что многие программы Unix написаны таким образом, что различные пути жестко запрограммированы в программе во время компиляции, и потребуется тонна работы и координации. изменить это, когда вы имеете дело с тысячами пакетов и их сопровождающих. Координация особенно трудна в мире Unix, так как существует довольно много поставщиков систем, в отличие от Windows, где Microsoft может в значительной степени диктовать изменения - и даже у Microsoft есть проблемы с тем, чтобы все встали на свои места, отсюда необходимость таких мер совместимости, как Виртуализация UAC.
Если углубиться в проблему жестко заданного пути, рассмотрим программу foo которая должна иметь доступ к своей базе данных. Где этот файл? Вероятный путь - /usr/share/foo/foo.db , который будет жестко задан в программе, чтобы он точно знал, где искать. Вы можете возразить, что программа может просто попробовать $HOME/usr/share/foo/foo.db или аналогичный, если она не находит свой жестко закодированный файл. Это правда, и это было бы неплохо, за исключением того, что не существует реального стандарта или соглашения для такого рода вещей, поэтому большинство программ просто не реализуют такой резервный механизм (эта проблема координации, опять же). И, возможно, это также добавляет сложности, которая приносит пользу относительно небольшой части населения, но это еще одна червя.
Связанная проблема заключается в том, как программа загружает разделяемые библиотеки, от которых она зависит. Динамический компоновщик, ld.so , должен знать, где найти все эти общие библиотеки. По сути, список путей может быть (снова) жестко закодирован в исполняемый файл во время компиляции, и в этом случае ld.so будет искать эти пути; в противном случае ld.so ищет каталоги, настроенные в /etc/ld.so.conf . Эту проблему на самом деле относительно легко решить, например, путем соответствующей установки переменной среды LD_LIBRARY_PATH .
Итак, суть в том, что многие программы не предназначены для гибкого (во время выполнения) способа поиска своих файлов, и, следовательно, разработчики пакетов не считают целесообразным предлагать вариант установки поочередно. каталоги. Дело не в том, что это технически невозможно - просто до сих пор не было желания создать стандарт и заставить всех следовать ему. Для примера, показывающего, как это технически невозможно, вы можете взглянуть на мой ответ на этот вопрос: установить git на сервер без sudo. Обратите внимание, что это своего рода уродливый обходной путь, и это печальное положение вещей.
Напомню, что я на самом деле разделяю ваше разочарование в связи с тем, что не удается легко установить бинарные пакеты в альтернативных местах, и я потратил много времени и усилий на то, чтобы скомпилировать пакеты вручную или обойти проблемы с упаковкой (способами, аналогичными вопрос, на который я ссылался в предыдущем абзаце) при работе в системах, где системные администраторы не хотят устанавливать пакеты, которые я хочу использовать.
