Gerenciadores de pacotes não raiz

De minha pesquisa, pareço perceber que todos os gerenciadores de pacotes insistem em serem usados ​​como usuários privilegiados e devem ser instalados /.

Normalmente, o que eu gosto de fazer é criar uma conta descartável, compilar algum software e instalar $HOMEnessa conta. Posso experimentar várias configurações e, quando terminar, apenas destrua a conta.

No entanto, compilar software se torna tedioso.

Minha experiência é realmente apenas limitada a yum, mas não entendo por que não seria possível soltar um arquivo de repo ~/etc/yum.repos.de fazer com que yum instalasse tudo em uma conta doméstica.

Existe alguma razão pela qual os gerenciadores de pacotes devem ser usados ​​como um usuário privado para instalar o software?

Pacotes binários são compilados com a suposição de que eles serão instalados em locais específicos no /. Isso nem sempre é facilmente alterado e seria necessário um esforço adicional de controle de qualidade (o que é bastante difícil em primeiro lugar!) Para determinar se os binários específicos são ou nã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 raiz, mas isso é tedioso e frágil.

Você terá mais sorte com os pacotes fonte. Gentoo Prefix e Rootless GoboLinux são gerenciadores de pacotes que podem ser instalados em /locais não locais e podem ser utilizados por não rootusuários.

Há um projeto de gerenciador de pacotes - Nix - com uma ideia fundamental interessante (um gerenciador de pacotes " funcional "), que também suporta uma operação por usuário:

Suporte multiusuário

A partir da versão 0.11, o Nix possui suporte para vários usuários. Isso significa que usuários sem privilégios podem instalar software com segurança. Cada usuário pode ter um perfil diferente, um conjunto de pacotes na loja Nix que aparecem no PATH do usuário. Se um usuário instalar um pacote que outro usuário já tenha instalado anteriormente, o pacote não será criado ou baixado uma segunda vez. Ao mesmo tempo, não é possível que um usuário injete um cavalo de Tróia em um pacote que possa ser usado por outro usuário.

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

Também há uma grande coleção de pacotes associados que podem ser instalados com o gerenciador de pacotes Nix - Nixpkgs --built para várias plataformas :

• GNU / Linux no x86 de 32 e 64 bits (i686-linux e x86_64-linux)
• Mac OS X (i686-darwin e x86_64-darwin)
• FreeBSD (i686-freebsd e x86_64-freebsd)
• OpenBSD (i686-openbsd)
• Windows / Cygwin (i686-cygwin),

e uma distribuição associada-- NixOS :

NixOS é uma distribuição Linux baseada no Nix. Ele usa o Nix não apenas para gerenciamento de pacotes, mas também para gerenciar a configuração do sistema (por exemplo, para criar arquivos de configuração em / etc). Isso significa, entre outras coisas, que é possível reverter facilmente toda a configuração do sistema para um estado anterior. Além disso, os usuários podem instalar software sem privilégios de root. Consulte Mais informação…

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

Primeiro de tudo, é devido a dependências. Alguns pacotes podem não ser instalados pelo PolicyKit, como o usuário. Portanto, seria necessário um encargo adicional para o empacotador que doar seu tempo livre e geralmente instalar o programa é tão fácil quanto digitar sudo(estação de usuário único) ou administrador persistente.

Existem opções para instalação no $ HOME

• Os 'gerenciadores de pacotes' primitivos da linguagem geralmente o suportam imediatamente (como gem para Ruby ou cabal para Haskell) ou com pequenos ajustes (esqueci o nome de python)
• Boa idade ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(ou variedades como jhbuild).
• Havia um programa para instalar no $ HOME alguns anos atrás. No entanto, não consigo encontrá-lo - acho que quase ninguém o usou, pois eles próprios os instalaram ou importunaram os administradores.

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

Ele permite que seu sistema personalizado dentro do diretório inicial seja acessível via proot e, portanto, você pode instalar qualquer pacote sem privilégios de root. Ele será executado corretamente em todas as principais distribuições Linux, a única limitação é que o JuJu pode ser executado no kernel Linux com a versão mínima recomendada 2.6.32.

Outro com um modelo bastante diferente é o 0install . É baseado na idéia de que você realmente não instala pacotes, mas apenas os executa a partir de um espaço de nomes global que baixa, compila, se necessário, e armazena em cache o software que você deseja usar.

Se você está bem com a compilação a partir da origem e a resolução de dependências, querendo principalmente que o gerenciador de pacotes lide com as operações de implantação / remoção da implementação / atualização, você pode dar uma olhada no GNU Stow ou no XStow um pouco aprimorado . Com eles, você prepara a instalação para um diretório separado (normalmente abaixo $PREFIX/stow) e, em seguida, armazena links simbólicos para o software a partir do seu prefixo real. Isso facilita a remoção completa do software. Uso-o com êxito para gerenciar meu software instalado na minha universidade.

Minha experiência é realmente limitada ao yum, mas não entendo por que não seria possível soltar um arquivo de repo em ~ / etc / yum.repos.d e fazer com que o yum instalasse tudo em uma conta doméstica.

Os principais gerenciadores de pacotes do Linux veem o mundo como um administrador de sistemas ... 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 seja utilizável, tenha versões rpmdb e faça coisas como "yum --security update" etc.

Existem alguns gerenciadores de pacotes, como a instalação zero, que tentam ver o mundo como um usuário faria ... ie. o que aplicações fazer eu ter acesso.

Você pode pensar que o posterior é um modelo melhor, mas IMNSHO há um motivo pelo qual você nunca ouviu falar de instalação zero, mas ouviu falar do yum.

Há um garoto novo no bloco: " JuNest ( Jailed User NEST) - a distribuição baseada no Arch Linux que roda em qualquer distribuição Linux sem acesso root." @ https://github.com/fsquillace/junest O Advantage é que ele não introduz um novo tipo de formato de pacote; portanto, após uma instalação muito fácil (no mínimo: cerca de 320 milhões), o repositório completo do Arch Linux (mais de 13.000 pacotes ATM) está ao seu alcance.

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, eu não conheço nenhuma das melhores interfaces que são capazes de fazer isso (por exemplo slapt-get, tanto quanto eu sei, não é possível). Teoricamente, você deve ser capaz de criar um alias installpkgpara installpkg --root ~/Apps- no entanto, acho que a maioria dos frontends exige root para executar, o que derrota o ponto.

Eu sugiro http://linuxbrew.sh/

É basicamente uma bifurcação para o macOS e possui binários pré-compilados para uso ...

Especialmente bom para lidar com versões mais antigas do gcc.

Se você realmente deseja instalar manualmente, um guia útil é http://www.linuxfromscratch.org/

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

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

Porém, quando você executar o seu programa, precisará modificar o LD_LIBRARY_PATH para carregar as bibliotecas dependentes. Além disso, isso não cuidará de nenhuma dependência.

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 acima não tem bibliotecas dependentes, caso contrário você teria que usar algo como:

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