Менеджеры не-корневых пакетов

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

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

Однако компиляция программного обеспечения становится утомительной.

Мой опыт на самом деле просто ограничен yum, но я не понимаю, почему я не смогу перетащить файл репо ~/etc/yum.repos.dи заставить yum установить все в домашнюю учетную запись.

Есть ли какая-либо причина, по которой менеджеры пакетов должны использоваться в качестве привилегированного пользователя для установки программного обеспечения?

Бинарные пакеты компилируются с предположением, что они будут установлены в определенных местах в /. Это не всегда легко изменить, и потребуются дополнительные усилия по обеспечению качества (что, во-первых, достаточно сложно!), Чтобы определить, являются ли конкретные двоичные файлы перемещаемыми или нет.

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

Вам повезет с исходными пакетами. Gentoo Prefix и Rootless GoboLinux - это менеджеры пакетов, которые могут устанавливаться в других /местах и ​​могут использоваться не rootпользователями.

Есть проект менеджера пакетов - Nix - с интересной фундаментальной идеей (« функциональный » менеджер pkg), который также поддерживает операции для каждого пользователя:

Многопользовательская поддержка

Начиная с версии 0.11, Nix имеет многопользовательскую поддержку. Это означает, что непривилегированные пользователи могут безопасно устанавливать программное обеспечение. У каждого пользователя может быть свой профиль, набор пакетов в хранилище Nix, которые появляются в PATH пользователя. Если пользователь устанавливает пакет, который другой пользователь уже установил ранее, пакет не будет собран или загружен во второй раз. В то же время один пользователь не может внедрить троянский конь в пакет, который может использоваться другим пользователем.

ПРИМЕЧАНИЕ, которое я хочу добавить: Nix должно использоваться в Unix-подобной системе по вашему выбору (например, в дистрибутиве Linux).

Существует также связанная большая коллекция пакетов, которые можно установить с помощью диспетчера пакетов Nix - Nixpkgs --built для ряда платформ :

• GNU / Linux в 32-разрядной и 64-разрядной версиях x86 (i686-linux и x86_64-linux)
• Mac OS X (i686-дарвин и x86_64-дарвин)
• FreeBSD (i686-freebsd и x86_64-freebsd)
• OpenBSD (i686-openbsd)
• Windows / Cygwin (i686-cygwin),

и связанный дистрибутив-- NixOS :

NixOS - это дистрибутив Linux, основанный на Nix. Он использует Nix не только для управления пакетами, но и для управления конфигурацией системы (например, для создания файлов конфигурации в / etc). Это означает, среди прочего, что можно легко откатить всю конфигурацию системы до более раннего состояния. Также пользователи могут устанавливать программное обеспечение без прав root. Читать далее…

и связанная с ним "непрерывная" система сборки - Hydra .

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

В $ HOME есть варианты установки

• Примитивные языковые «менеджеры пакетов» обычно поддерживают его «из коробки» (например, gem для Ruby или cabal для Haskell) или с небольшими изменениями (я забыл название для python)
• Старый добрый ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(или вариации вроде jhbuild).
• Там была программа для установки в $ HOME несколько лет назад. Однако я не могу найти его - я полагаю, что почти никто не использовал его, так как они устанавливали его сами или ворчали администраторы.

Я использую JuJu, который в основном позволяет иметь очень маленький дистрибутив linux (содержащий только менеджер пакетов) внутри вашего каталога $ HOME / .juju.

Это позволяет иметь собственную систему внутри домашнего каталога, доступную через proot, и, следовательно, вы можете устанавливать любые пакеты без прав root. Он будет работать правильно для всех основных дистрибутивов Linux, единственное ограничение - JuJu может работать на ядре Linux с минимальной рекомендованной версией 2.6.32.

Другой с довольно другой моделью - 0install . Он основан на идее, что вы на самом деле не устанавливаете пакеты, а просто запускаете их из глобального пространства имен, которое загружает, компилирует при необходимости и кэширует программное обеспечение, которое вы хотите использовать.

Если вы хорошо справляетесь с компиляцией из исходного кода и разрешаете зависимости самостоятельно, в первую очередь желая, чтобы диспетчер пакетов обрабатывал операции развертывания / отмены развертывания / обновления, вы, возможно, захотите взглянуть на GNU Stow или несколько улучшенный XStow . С ними вы устанавливаете установку в отдельный каталог (обычно в $PREFIX/stow), а затем укладываете символические ссылки на программное обеспечение из своего реального префикса. Это позволяет легко полностью удалить программное обеспечение. Я успешно использую его для управления своим программным обеспечением, установленным в моем университете.

Мой опыт на самом деле ограничен только yum, но я не понимаю, почему я не смогу перенести файл репо в ~ / etc / yum.repos.d и заставить yum установить все в домашнюю учетную запись.

Основные менеджеры пакетов Linux рассматривают мир как системный администратор ... где машина является единым целым. Это позволяет получить ответы на такие вопросы, как «какие выдающиеся ошибки относятся к системе X» и «чем отличаются система X и система Y». Это также позволяет yum иметь «историю», которую можно использовать, иметь версии rpmdb и выполнять такие действия, как «yum --security update» и т. Д.

Есть некоторые менеджеры пакетов, такие как zero-install, которые пытаются посмотреть на мир так, как это делает пользователь ... т.е. к каким приложениям у меня есть доступ.

Вы можете подумать, что последняя модель лучше, но у IMNSHO есть причина, по которой вы не слышали о нулевой установке, но слышали о yum.

В этом блоке появился новый ребенок: « JuNest ( JAiled User NEST) - основанный на Arch Linux дистрибутив, который работает на любом дистрибутиве Linux без root-доступа». @ https://github.com/fsquillace/junest Преимущество заключается в том, что он не вводит новый тип формата пакета, поэтому после очень простой установки (минимум: около 320 млн.) полный репозиторий Arch Linux (более 13000). пакеты банкоматов) у вас под рукой.

Инструменты, используемые Slackware, в частности installpkg, могут. Со страницы руководства:

--root /otherroot
       Install using a location other than / (the default) as the root of the 
       filesystem to install on. In the example given, use /otherroot instead.
       Setting the ROOT environment variable does the same thing.

Тем не менее, я не знаю ни одного из лучших интерфейсов, способных сделать это (например slapt-get, насколько я знаю, не могу этого сделать). Теоретически, вы должны быть в состоянии псевдоним installpkgк installpkg --root ~/Apps- однако, я думаю , что большинство фронтэнды требует корня для запуска, которая побеждает точку.

Я бы предложил http://linuxbrew.sh/

Это в основном форк brew для macOS и имеет предварительно скомпилированные двоичные файлы для использования ...

Особенно хорошо подходит для работы со старыми версиями gcc.

Если вы действительно хотите установить вручную, полезное руководство http://www.linuxfromscratch.org/

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

Вы можете попытаться распаковать файлы rpm (rpm2cpio package.rpm | cpio -idmv) в каталоге по вашему выбору.

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

Пример:

# mkdir new_root
# cd new_root
# wget ftp://mirror.switch.ch/pool/4/mirror/centos/6.7/os/x86_64/Packages/vim-enhanced-7.4.629-5.el6.x86_64.rpm
# rpm2cpio vim-enhanced-7.4.629-5.el6.x86_64.rpm | cpio -idmv
# ./usr/bin/vim -version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 24 2015 02:23:23)

Выше нет зависимых библиотек, в противном случае вам придется использовать что-то вроде:

export LD_LIBRARY_PATH=./usr/lib ./usr/bin/program