Gestionnaires de paquets non-root

D'après mes recherches, il semble que tous les gestionnaires de paquets insistent pour être utilisés en tant qu'utilisateur privilégié et doivent être installés dans /.

Généralement, ce que j'aime faire, c'est créer un compte jetable, compiler des logiciels et installer $HOMEpour ce compte. Je peux essayer diverses configurations puis, une fois terminé, il suffit de détruire le compte.

Cependant, compiler un logiciel devient fastidieux.

Mon expérience est vraiment juste limitée à yum, mais je ne comprends pas pourquoi je ne serais pas capable de déposer un fichier repo ~/etc/yum.repos.det de laisser yum tout installer dans un compte personnel.

Y a-t-il une raison pour laquelle les gestionnaires de paquets doivent être utilisés en tant qu'utilisateur privilégié pour installer le logiciel?

Les packages binaires sont compilés en supposant qu’ils seront installés à des emplacements spécifiques dans /. Cela ne change pas toujours facilement, et il faudrait un effort supplémentaire d'assurance qualité (ce qui est assez difficile au départ!) Pour déterminer si des fichiers binaires spécifiques sont ou ne peuvent pas être déplacés.

Dans une certaine mesure, vous pouvez utiliser des éléments tels que fakechroot pour créer un système entier dans un sous-répertoire en tant qu'utilisateur non root, mais cela est fastidieux et fragile.

Vous aurez plus de chance avec les paquets sources. Gentoo Prefix et Rootless GoboLinux sont tous deux des gestionnaires de paquets pouvant être installés dans des /emplacements autres que des emplacements et pouvant être utilisés par des rootutilisateurs autres que les utilisateurs.

Il y a un projet de gestionnaire de paquets - Nix - avec une idée fondamentale intéressante (un gestionnaire de paquets " fonctionnel "), qui prend également en charge une opération par utilisateur:

Support multi-utilisateur

À partir de la version 0.11, Nix prend en charge plusieurs utilisateurs. Cela signifie que les utilisateurs non privilégiés peuvent installer des logiciels en toute sécurité. Chaque utilisateur peut avoir un profil différent, un ensemble de packages dans le magasin Nix qui apparaissent dans le chemin PATH de l'utilisateur. Si un utilisateur installe un package déjà installé par un autre utilisateur, il ne sera ni créé ni téléchargé une seconde fois. Dans le même temps, il est impossible pour un utilisateur d'injecter un cheval de Troie dans un package pouvant être utilisé par un autre utilisateur.

A NOTE, JE VEUX AJOUTER: Nix devrait être utilisable dans un système de type Unix de votre choix (par exemple, une distribution Linux).

Il existe également une grande collection de packages associés pouvant être installés avec le gestionnaire de packages Nix - Nixpkgs --built pour un certain nombre de plates - formes :

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

et une distribution associée - NixOS :

NixOS est une distribution Linux basée sur Nix. Il utilise Nix non seulement pour la gestion des paquets, mais également pour gérer la configuration du système (par exemple, pour créer des fichiers de configuration dans / etc). Cela signifie, entre autres choses, qu'il est possible de restaurer facilement la configuration complète du système à un état antérieur. De plus, les utilisateurs peuvent installer des logiciels sans privilèges root. Lire la suite…

et un système de construction "continu" associé - Hydra .

Tout d'abord, c'est dû aux dépendances. Certains paquets peuvent ne pas être installés par l'utilisateur, comme PolicyKit. Par conséquent, il exigerait une charge supplémentaire pour le conditionneur qui donne son temps libre et l'installation du programme est généralement aussi simple que la dactylographie sudo(station mono-utilisateur) ou un administrateur ennuyeux.

Il y a des options pour installer dans $ HOME

• Les 'gestionnaires de paquets' primitifs en langue les prennent généralement en charge à la sortie de la boîte (comme une gemme pour Ruby ou une cabale pour Haskell) ou avec de petites modifications (j'ai oublié le nom pour python)
• Bon vieux ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(ou varitations comme jhbuild).
• Il y avait un programme à installer chez $ HOME il y a quelques années. Cependant, je ne le trouve pas - je suppose que presque personne ne l’utilisait, qu’ils l’aient installé eux-mêmes ou que des administrateurs fous.

J'utilise JuJu, ce qui permet d'avoir une très petite distribution Linux (contenant uniquement le gestionnaire de paquets) dans votre répertoire $ HOME / .juju.

Il vous permet d’avoir votre système personnalisé dans le répertoire personnel accessible via proot et, par conséquent, vous pouvez installer n’importe quel paquet sans privilèges root. Il fonctionnera correctement sur toutes les principales distributions Linux. La seule limitation est que JuJu peut être exécuté sur un noyau Linux avec la version minimum recommandée 2.6.32.

Un autre modèle avec un modèle assez différent est 0install . Cela repose sur l'idée que vous n'installez pas vraiment de paquet, mais les exécutez simplement à partir d'un espace de noms global qui télécharge, compile si nécessaire et met en cache le logiciel que vous souhaitez utiliser.

Si vous voulez compiler à partir du source et résoudre les dépendances vous-même, principalement pour que le gestionnaire de paquets gère les opérations de déploiement / annulation de déploiement / mise à niveau, jetez un coup d'œil à GNU Stow ou à la version légèrement améliorée de XStow . Grâce à eux, vous installez l’installation dans un répertoire distinct (généralement situé sous $PREFIX/stow), puis vous stockez les liens symboliques vers le logiciel à partir de votre préfixe réel. Cela facilite ensuite la suppression complète du logiciel. Je l'utilise avec succès pour gérer mon logiciel installé sur mesure dans mon université.

Mon expérience est vraiment limitée à yum, mais je ne comprends pas pourquoi je ne pourrais pas déposer un fichier de dépôt dans ~ / etc / yum.repos.d et laisser yum tout installer dans un compte personnel.

Les gestionnaires de paquets Linux classiques voient le monde comme un administrateur système… où la machine est une entité unique. Cela vous permet d'obtenir des réponses à des questions telles que "quels errata en suspens s'appliquent au système X" et "en quoi le système X et le système Y diffèrent-ils". Cela permet également à yum d'avoir "une histoire" qui soit utilisable, d'avoir des versions de rpmdb et de faire des choses comme "yum --security update" etc.

Certains gestionnaires de paquets, comme zero-install, essaient de voir le monde comme un utilisateur le ferait ... c'est-à-dire. À quelles applications ai - je accès?

Vous pensez peut-être que ce dernier modèle est meilleur, mais IMNSHO, il y a une raison pour laquelle vous n'avez pas entendu parler de l'installation nulle mais avez entendu parler de yum.

Il y a un petit nouveau sur le bloc: « JuNest (Emprisonné utilisateur NEST) - L'Arc distro basé sur Linux qui fonctionne sur une distro Linux sans accès root. » @ https://github.com/fsquillace/junest L' avantage est qu'il n'introduit pas un nouveau type de format de paquet, donc après une installation très simple (minimum: environ 320M), le référentiel complet Arch Linux (plus de 13 000 forfaits ATM) est à portée de main.

Les outils utilisés par Slackware, en particulier installpkg, peuvent. De la page de manuel:

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

Cependant, je ne connais aucun des meilleurs serveurs pouvant le faire (p slapt-get. Ex. , Autant que je sache, ne peut pas le faire). En théorie, vous devriez être en mesure d'alias installpkgà installpkg --root ~/Apps- cependant, je pense que la plupart des frontends exigent la racine à courir, ce qui va à l' encontre du point.

Je suggérerais http://linuxbrew.sh/

Il s’agit essentiellement d’une fourchette d’infusion pour macOS et contient des fichiers binaires précompilés destinés à être utilisés ...

Particulièrement idéal pour gérer les anciennes versions de gcc.

Si vous voulez vraiment installer à la main, un guide utile est http://www.linuxfromscratch.org/

Yum doit écrire dans la base de données, qui appartient à root. Pour cette raison, vous ne pouvez pas l'utiliser en tant qu'utilisateur normal.

Vous pouvez essayer de décompresser des fichiers rpm (rpm2cpio package.rpm | cpio -idmv) dans un répertoire de votre choix.

Mais lorsque vous exécuterez votre programme, vous devrez prendre soin de modifier LD_LIBRARY_PATH afin de charger les bibliothèques dépendantes. En outre, cela ne prendra pas en charge les dépendances.

Exemple:

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

Ce qui précède n'a pas de bibliothèque dépendante, sinon vous devriez utiliser quelque chose comme:

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