Gerenciadores de Pacotes Não-Raiz

Question

Da minha pesquisa, pareço notar que todos os gerenciadores de pacotes insistem em ser usados como um usuário privilegiado e devem ser instalados em / .

Normalmente, o que eu gosto de fazer é criar uma conta descartável, compilar algum software e instalar em $HOME para essa conta. Eu posso tentar uma variedade de configurações e quando terminar, apenas destrua a conta.

No entanto, compilar software torna-se tedioso.

Minha experiência é limitada a yum , mas não entendo por que não seria possível descartar um arquivo de repo em ~/etc/yum.repos.d e fazer com que o yum instale tudo em uma conta inicial.

Existe alguma razão pela qual os gerenciadores de pacotes devem ser usados como usuários privados para instalar software?

    

Answer 1

Os pacotes binários são compilados com a suposição de que eles serão instalados em locais específicos em / . Isso nem sempre é facilmente alterado, e seria preciso um esforço adicional de controle de qualidade (o que é difícil o suficiente em primeiro lugar!) Para determinar se binários específicos são ou não são realocáveis.

Até certo ponto, você pode usar coisas como fakechroot para criar um sistema inteiro em um subdiretório como um usuário não-root, mas isso é tedioso e frágil.

Você terá mais sorte com os pacotes-fonte. Prefixo do Gentoo e GoboLinux sem raiz são ambos gerenciadores de pacotes que podem ser instalados em locais que não são / e podem ser usados por usuários que não são root .

    

Answer 2

Existe um projeto de gerenciador de pacotes - Nix - com uma ideia básica interessante (a "< em> funcional "pkg manager", que também suporta uma operação por usuário:

Multi-user support

Starting at version 0.11, Nix has multi-user support. This means that non-privileged users can securely install software. Each user can have a different profile, a set of packages in the Nix store that appear in the user’s PATH. If a user installs a package that another user has already installed previously, the package won’t be built or downloaded a second time. At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user.

UMA NOTA QUE EU QUERO ADICIONAR: Nix deve ser utilizável em um sistema semelhante ao Unix de sua escolha (por exemplo, uma distribuição Linux).

Há também uma grande coleção de pacotes associados que podem ser instalados com o gerenciador de pacotes Nix - Nixpkgs--construído para várias plataformas :

• GNU/Linux on 32-bit and 64-bit x86 (i686-linux and x86_64-linux)
• Mac OS X (i686-darwin and x86_64-darwin)
• FreeBSD (i686-freebsd and x86_64-freebsd)
• OpenBSD (i686-openbsd)
• Windows / Cygwin (i686-cygwin),

e uma distro associada - NixOS :

NixOS is a Linux distribution based on Nix. It uses Nix not just for package management but also to manage the system configuration (e.g., to build configuration files in /etc). This means, among other things, that it’s possible to easily roll back the entire configuration of the system to an earlier state. Also, users can install software without root privileges. Read more…

e um sistema de construção "contínuo" associado - Hydra .

    

Answer 3

Primeiro de tudo, é devido a dependências. Alguns pacotes podem não ser instalados pelo usuário - como o PolicyKit. Portanto, isso exigiria uma sobrecarga adicional no empacotador que doa seu tempo livre e, geralmente, a instalação do programa é tão fácil quanto digitar sudo (estação de usuário único) ou o administrador irritante.

Existem opções para instalar em $ HOME

• Linguagem primitiva 'gerenciadores de pacotes' geralmente suporta fora da caixa (como gem para Ruby ou cabal para Haskell) ou com pequenos ajustes (esqueci o nome de python)
• Bom e velho ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install (ou varitações como jhbuild).
• O foi programa para instalar em $ HOME alguns anos atrás. No entanto, eu não consigo encontrá-lo - eu acho que quase ninguém usou isso como eles mesmos os instalaram ou importunam os administradores.

Answer 4

Eu uso JuJu que basicamente permite ter uma distribuição linux realmente pequena (contendo apenas o gerenciador de pacotes) dentro do seu $ HOME / diretório .juju.

Permite ter seu sistema customizado dentro do diretório home acessível via proot e, portanto, você pode instalar quaisquer pacotes sem privilégios de root. Ele será executado corretamente para todas as principais distribuições de Linux, a única limitação é que o JuJu pode rodar no kernel do linux com a versão 2.6.32 recomendada.

    

Answer 5

Outro com um modelo diferente é 0install . Baseia-se na idéia de que você não instala pacotes de fato, mas simplesmente os executa a partir de um namespace global que baixa, compila, se necessário, e armazena em cache o software que deseja usar.

    

Answer 6

Se você estiver bem compilando a partir de fontes e resolvendo dependências, principalmente querendo que o gerenciador de pacotes lide com operações de deploy / undeploy / upgrade, você pode querer dar uma olhada em GNU Stow ou o pouco melhor XStow . Com eles, você coloca a instalação em um diretório separado (geralmente em $PREFIX/stow ) e então armazena links simbólicos para o software a partir do seu prefixo real. Isso facilita a remoção do software completamente. Eu uso com sucesso para gerenciar meu software personalizado instalado em minha universidade.

    

Answer 7

My experience is really just limited to yum, but I don't understand why I wouldn't be able to drop a repo file into ~/etc/yum.repos.d and have yum install everything into a home account.

Os gerentes de pacotes principais do Linux vêem o mundo como um administrador de sistema ... onde a máquina é uma entidade única. Isso permite que você obtenha respostas para perguntas como "quais erratas pendentes se aplicam ao sistema X" e "como o sistema X e o sistema Y diferem". Isso também permite que o yum tenha "um histórico" que é utilizável, tenha versões rpmdb e faça coisas como "yum - update de segurança" etc.

Existem alguns gerenciadores de pacotes, como o zero-install, que tentam ver o mundo como um usuário faria ... ie. quais aplicações fazem eu ter acesso.

Você pode pensar que o último é um modelo melhor, mas o IMNSHO tem uma razão pela qual você não ouviu falar de instalação zero, mas já ouviu falar do yum.

    

Answer 8

Há um novo garoto no bloco: " JuNest (NEST do Usuário Protegido) - A distro baseada no Arch Linux que roda em qualquer distribuição Linux sem acesso root." @ link A vantagem é que ele não introduz um novo tipo de formato de pacote, portanto, após uma instalação muito fácil (mínimo: cerca de 320M), o repositório completo do Arch Linux (mais de 13000 pacotes ATM) está ao seu alcance.

    

Answer 9

As ferramentas usadas pelo Slackware, especificamente installpkg , podem. Na página do manual:

--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.

No entanto, não conheço nenhum dos melhores frontends que possam fazer isso (por exemplo, slapt-get , até onde eu sei, não pode fazer isso). Teoricamente, você deve ser capaz de alias installpkg to installpkg --root ~/Apps - no entanto, eu acho que a maioria dos frontends requer que o root rode, o que derrota o ponto.

    

Answer 10

Sugiro o link

É basicamente um fork do brew para macOS e tem binários pré-compilados para uso ...

Especialmente excelente para lidar com versões antigas do gcc.

Se você realmente deseja instalar manualmente, um guia útil é link

    

Answer 11

O Yum precisa gravar no banco de dados, que é próprio por raiz. Por causa disso, você não pode usá-lo como usuário normal.

Você pode tentar descompactar arquivos rpm (rpm2cpio package.rpm | cpio -idmv) dentro de um diretório de sua preferência.

Mas quando você vai executar o seu programa, você terá que tomar cuidado para modificar o LD_LIBRARY_PATH para carregar as bibliotecas dependentes. Também isso não vai cuidar de quaisquer dependências.

Exemplo:

# 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)

O texto acima não tem nenhuma biblioteca dependente, caso contrário você teria que usar algo como:

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