Gestori di pacchetti non root

Dalla mia ricerca, mi sembra di notare che tutti i gestori di pacchetti insistono per essere utilizzati come utenti privilegiati e devono essere installati /.

In genere, ciò che mi piace fare è creare un account usa e getta, compilare un software e installarlo $HOMEper quell'account. Posso provare una varietà di configurazioni e poi quando ho finito, basta distruggere l'account.

Tuttavia, la compilazione del software diventa noiosa.

La mia esperienza è davvero limitata a yum, ma non capisco perché non sarei in grado di rilasciare un file repo ~/etc/yum.repos.de fare in modo che yum installi tutto in un account home.

C'è qualche motivo per cui i gestori di pacchetti devono essere utilizzati come utenti privati ​​per installare il software?

I pacchetti binari vengono compilati supponendo che verranno installati in posizioni specifiche in /. Questo non è sempre facilmente modificabile e richiederebbe un ulteriore sforzo di QA (che è abbastanza difficile in primo luogo!) Per determinare se specifici binari sono o non possono essere trasferiti.

In una certa misura, puoi usare cose come fakechroot per creare un intero sistema in una sottodirectory come utente non root, ma questo è noioso e fragile.

Avrai più fortuna con i pacchetti sorgente. Gentoo Prefix e Rootless GoboLinux sono entrambi gestori di pacchetti che possono essere installati in /ubicazioni diverse e che possono essere utilizzati da rootutenti non utenti.

Esiste un progetto di gestore di pacchetti - Nix - con un'interessante idea di base (un gestore pkg " funzionale "), che supporta anche un'operazione per utente:

Supporto multiutente

A partire dalla versione 0.11, Nix ha il supporto multiutente. Ciò significa che gli utenti non privilegiati possono installare software in modo sicuro. Ogni utente può avere un profilo diverso, un set di pacchetti nel negozio Nix che appare nel PERCORSO dell'utente. Se un utente installa un pacchetto che un altro utente ha già installato in precedenza, il pacchetto non verrà creato o scaricato una seconda volta. Allo stesso tempo, non è possibile per un utente iniettare un cavallo di Troia in un pacchetto che potrebbe essere utilizzato da un altro utente.

UNA NOTA CHE VOGLIO AGGIUNGERE: Nix dovrebbe essere utilizzabile in un sistema simile a Unix di tua scelta (ad esempio, una distribuzione Linux).

Esiste anche una vasta raccolta associata di pacchetti che possono essere installati con il gestore pacchetti Nix - Nixpkgs - costruito per un numero di piattaforme :

• GNU / Linux su x86 a 32 e 64 bit (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 una distribuzione associata - NixOS :

NixOS è una distribuzione Linux basata su Nix. Utilizza Nix non solo per la gestione dei pacchetti, ma anche per gestire la configurazione del sistema (ad esempio, per creare file di configurazione in / etc). Ciò significa, tra l'altro, che è possibile ripristinare facilmente l'intera configurazione del sistema a uno stato precedente. Inoltre, gli utenti possono installare software senza i privilegi di root. Leggi di più…

e un sistema di costruzione "continuo" associato - Hydra .

Innanzitutto è dovuto alle dipendenze. Alcuni pacchetti potrebbero non essere installati dall'utente come PolicyKit. Pertanto richiederebbe un onere aggiuntivo per i packager che donano il loro tempo libero e di solito l'installazione del programma è facile come la digitazione sudo(stazione per utente singolo) o l'amministratore assillante.

Ci sono opzioni per l'installazione in $ HOME

• I "gestori di pacchetti" primitivi di lingua di solito lo supportano immediatamente (come gemma per Ruby o cabala per Haskell) o con piccole modifiche (ho dimenticato il nome per Python)
• Buon vecchio ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(o varianti come jhbuild).
• C'era un programma da installare su $ HOME qualche anno fa. Tuttavia, non riesco a trovarlo - immagino che quasi nessuno l'abbia usato perché li ha installati da soli o nag amministratori.

Uso JuJu che sostanzialmente permette di avere una distribuzione linux davvero piccola (contenente solo il gestore dei pacchetti) all'interno della directory $ HOME / .juju.

Permette di avere il proprio sistema personalizzato all'interno della home directory accessibile tramite proot e, quindi, è possibile installare tutti i pacchetti senza i privilegi di root. Funzionerà correttamente con tutte le principali distribuzioni di Linux, l'unica limitazione è che JuJu può funzionare su kernel Linux con la versione minima consigliata 2.6.32.

Un altro con un modello piuttosto diverso è 0install . Si basa sull'idea che non si installano realmente i pacchetti, ma li si esegue semplicemente da uno spazio dei nomi globale che scarica, compila se necessario e memorizza nella cache il software che si desidera utilizzare.

Se stai bene compilando da fonti e risolvendo tu stesso le dipendenze, principalmente volendo che il gestore pacchetti gestisca le operazioni di distribuzione / disimpegno / aggiornamento, potresti dare un'occhiata a GNU Stow o XStow in qualche modo migliorato . Con loro, metti in scena l'installazione in una directory separata (in genere sotto $PREFIX/stow) e poi fai collegamenti simbolici al software dal tuo vero prefisso. Ciò semplifica la rimozione completa del software. Lo uso con successo per gestire il mio software installato su misura presso la mia università.

La mia esperienza è davvero limitata a yum, ma non capisco perché non sarei in grado di rilasciare un file repo in ~ / etc / yum.repos.d e fare in modo che yum installi tutto in un account home.

I gestori di pacchetti Linux tradizionali considerano il mondo come un amministratore di sistema ... dove la macchina è una singola entità. Ciò consente di ottenere risposte a domande come "quali errori errati si applicano al sistema X" e "come differiscono il sistema X e il sistema Y". Ciò consente anche a yum di avere "una cronologia" utilizzabile, di avere versioni rpmdb e di fare cose come "yum --security update" ecc.

Ci sono alcuni gestori di pacchetti, come zero-install, che provano a vedere il mondo come farebbe un utente ... cosa applicazioni fare che hanno accesso.

Potresti pensare che il successivo sia un modello migliore, ma IMNSHO c'è una ragione per cui non hai sentito parlare di zero-install ma hai sentito parlare di yum.

C'è un nuovo bambino sul blocco: " JuNest ( JESTed User NEST) - La distribuzione basata su Arch Linux che funziona su qualsiasi distribuzione Linux senza accesso root." @ https://github.com/fsquillace/junest Il vantaggio è che non introduce un nuovo tipo di formato di pacchetto, quindi dopo un'installazione molto semplice (minimo: circa 320 M), il repository Arch Linux completo (oltre 13000 pacchetti ATM) è a portata di mano.

Gli strumenti utilizzati da Slackware, in particolare installpkg, possono. Dalla pagina man:

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

Tuttavia, non conosco nessuno dei migliori frontend che sono in grado di farlo (ad esempio slapt-get, per quanto ne so, non posso farlo). In teoria, si dovrebbe essere in grado di alias installpkga installpkg --root ~/Apps- tuttavia, penso che la maggior parte frontend richiedono root per eseguire, che sconfigge il punto.

Suggerirei http://linuxbrew.sh/

È fondamentalmente un fork di brew per macOS e ha binari precompilati per l'uso ...

Particolarmente indicato per la gestione di versioni precedenti di gcc.

Se vuoi davvero installare a mano, una guida utile è http://www.linuxfromscratch.org/

Yum deve scrivere nel database, che è proprietario di root. Per questo motivo non puoi usarlo come un normale utente.

Potresti provare a decomprimere i file rpm (rpm2cpio package.rpm | cpio -idmv) all'interno di una directory di tua scelta.

Ma quando eseguirai il tuo programma dovrai aver cura di modificare LD_LIBRARY_PATH per caricare le librerie dipendenti. Inoltre, questo non si occuperà di eventuali dipendenze.

Esempio:

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

Quanto sopra non ha librerie dipendenti, altrimenti dovresti usare qualcosa del tipo:

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