Gerentes de paquetes no root

De mi investigación, me parece notar que todos los administradores de paquetes insisten en ser utilizados como usuarios privilegiados y deben instalarse en ellos /.

Por lo general, lo que me gusta hacer es crear una cuenta de usar y tirar, compilar algún software e instalar $HOMEpara esa cuenta. Puedo probar una variedad de configuraciones y luego, cuando termine, simplemente destruya la cuenta.

Sin embargo, compilar software se vuelve tedioso.

Mi experiencia realmente se limita a yum, pero no entiendo por qué no podría colocar un archivo de repositorio ~/etc/yum.repos.dy hacer que instale todo en una cuenta doméstica.

¿Hay alguna razón por la cual los administradores de paquetes se deben utilizar como usuarios privilegiados para instalar software?

Los paquetes binarios se compilan con el supuesto de que se instalarán en ubicaciones específicas en /. Esto no siempre se cambia fácilmente, y se necesitaría un esfuerzo adicional de control de calidad (¡lo cual es bastante difícil en primer lugar!) Para determinar si los archivos binarios específicos son o no reubicables.

Hasta cierto punto, puede usar cosas como fakechroot para crear un sistema completo en un subdirectorio como usuario no root, pero esto es tedioso y frágil.

Tendrás mejor suerte con los paquetes fuente. Gentoo Prefix y Roboless GoboLinux son dos administradores de paquetes que pueden instalarse en /ubicaciones que no son y pueden ser utilizados por personas que no sean rootusuarios.

Hay un proyecto de administrador de paquetes, Nix, con una idea fundamental interesante (un administrador de paquetes " funcional "), que también admite una operación por usuario:

Soporte multiusuario

A partir de la versión 0.11, Nix tiene soporte para múltiples usuarios. Esto significa que los usuarios sin privilegios pueden instalar software de forma segura. Cada usuario puede tener un perfil diferente, un conjunto de paquetes en la tienda Nix que aparecen en la RUTA del usuario. Si un usuario instala un paquete que otro usuario ya ha instalado anteriormente, el paquete no se compilará ni descargará por segunda vez. Al mismo tiempo, no es posible que un usuario inyecte un caballo de Troya en un paquete que pueda ser utilizado por otro usuario.

UNA NOTA QUE QUIERO AGREGAR: Nix debe ser utilizable en un sistema tipo Unix de su elección (por ejemplo, una distribución de Linux).

También hay una gran colección de paquetes asociados que se pueden instalar con el administrador de paquetes de Nix, Nixpkgs, creados para varias plataformas :

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

y una distribución asociada-- NixOS :

NixOS es una distribución de Linux basada en Nix. Utiliza Nix no solo para la gestión de paquetes, sino también para gestionar la configuración del sistema (por ejemplo, para crear archivos de configuración en / etc). Esto significa, entre otras cosas, que es posible revertir fácilmente toda la configuración del sistema a un estado anterior. Además, los usuarios pueden instalar software sin privilegios de root. Lee mas…

y un sistema de construcción "continuo" asociado: Hydra .

En primer lugar, se debe a dependencias. Algunos paquetes pueden no ser instalados por el usuario, como PolicyKit. Por lo tanto, requeriría una carga adicional para el empaquetador que dona su tiempo libre y, por lo general, la instalación del programa es tan fácil como escribir sudo(estación de usuario único) o administrador molesto.

Hay opciones para instalar en $ HOME

• Los 'gestores de paquetes' primitivos del lenguaje generalmente lo admiten fuera de la caja (como gema para Ruby o cabal para Haskell) o con pequeños ajustes (olvidé el nombre para python)
• Bien viejo ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(o variaciones como jhbuild).
• Hubo un programa para instalar en $ HOME hace unos años. Sin embargo, no puedo encontrarlo, supongo que casi nadie lo usó ya que los instalaron ellos mismos o molestaron a los administradores.

Uso JuJu, que básicamente permite tener una distribución de Linux realmente pequeña (que contiene solo el administrador de paquetes) dentro de su directorio $ HOME / .juju.

Permite tener su sistema personalizado dentro del directorio de inicio accesible a través de proot y, por lo tanto, puede instalar cualquier paquete sin privilegios de root. Se ejecutará correctamente en todas las distribuciones principales de Linux, la única limitación es que JuJu puede ejecutarse en el núcleo de Linux con la versión mínima recomendada 2.6.32.

Otro con un modelo bastante diferente es 0install . Se basa en la idea de que realmente no instala paquetes, sino que simplemente los ejecuta desde un espacio de nombres global que descarga, compila si es necesario y almacena en caché el software que desea utilizar.

Si está bien compilando desde el origen y resolviendo dependencias usted mismo, principalmente desea que el administrador de paquetes maneje las operaciones de despliegue / despliegue / actualización, es posible que desee echar un vistazo a GNU Stow o al XStow algo mejorado . Con ellos, organiza la instalación en un directorio separado (generalmente debajo $PREFIX/stow) y luego almacena enlaces simbólicos al software desde su prefijo real. Esto facilita la eliminación del software por completo. Lo uso con éxito para administrar mi software personalizado instalado en mi universidad.

Mi experiencia se limita a yum, pero no entiendo por qué no podría dejar un archivo de repositorio en ~ / etc / yum.repos.d y hacer que yum instale todo en una cuenta doméstica.

Los principales administradores de paquetes de Linux ven el mundo como lo haría un administrador de sistemas ... donde la máquina es una sola entidad. Esto le permite obtener respuestas a preguntas como "qué erratas pendientes se aplican al sistema X" y "cómo difieren el sistema X y el sistema Y". Esto también le permite a yum tener "un historial" que se puede usar, tener versiones rpmdb y hacer cosas como "yum --security update", etc.

Hay algunos administradores de paquetes, como zero-install, que intentan ver el mundo como lo haría un usuario ... es decir. lo que las aplicaciones de hacer que tienen acceso.

Puede pensar que el último es un mejor modelo, pero IMNSHO hay una razón por la que no ha oído hablar de la instalación cero pero sí de yum.

Hay un nuevo chico en el bloque: " JuNest ( Jailed User NEST): la distribución basada en Arch Linux que se ejecuta en cualquier distribución de Linux sin acceso a la raíz". @ https://github.com/fsquillace/junest Advantage es que no introduce un nuevo tipo de formato de paquete, así que después de una instalación muy fácil (mínimo: aproximadamente 320M), el repositorio completo de Arch Linux (más de 13000 paquetes ATM) está a su alcance.

Las herramientas utilizadas por Slackware, específicamente installpkg, pueden. Desde la página del 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.

Sin embargo, no conozco ninguna de las mejores interfaces que puedan hacer esto (por ejemplo slapt-get, hasta donde yo sé, no pueden hacer esto). Teóricamente, deberías poder usar alias installpkgpara installpkg --root ~/Apps, sin embargo, creo que la mayoría de las interfaces requieren que se ejecute root, lo que frustra el punto.

Sugeriría http://linuxbrew.sh/

Básicamente es una bifurcación de brebaje para macOS y tiene binarios precompilados para su uso ...

Especialmente bueno para manejar versiones anteriores de gcc.

Si realmente desea instalar a mano, una guía útil es http://www.linuxfromscratch.org/

Yum necesita escribir en la base de datos, que es propia de root. Debido a esto, no puede usarlo como un usuario normal.

Puede intentar descomprimir archivos rpm (rpm2cpio package.rpm | cpio -idmv) dentro de un directorio de su elección.

Pero cuando ejecute su programa, deberá modificar LD_LIBRARY_PATH para cargar las bibliotecas dependientes. Además, esto no se encargará de ninguna dependencia.

Ejemplo:

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

Lo anterior no tiene ninguna biblioteca dependiente, de lo contrario, tendría que usar algo como:

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