Esiste un modo per ottenere APT per installare i pacchetti nella mia home directory?
Non voglio apportare modifiche a livello di sistema.
In alternativa, ci sono gestori di pacchetti linux basati su home directory?
Risposte:
Dpkg non ha la funzione --relocate di RPM. Vale la pena considerare quanti pacchetti RPM supportano questa funzione. Fondamentalmente, non può essere fatto.
Quello che potresti fare è usare un chroot se vuoi testare qualcosa prima di installarlo globalmente sul sistema. Per fare ciò, devi essere in grado di ottenere l'accesso al root. La prima cosa da fare è creare un chroot di base:
# debootstrap lenny lenny-chroot
Questo crea un chroot di Lenny all'interno della lenny-chrootdirectory.
Ora possiamo inserire il chroot:
# chroot lenny-chroot
Ora possiamo fare tutto ciò che vogliamo e installare qualsiasi cosa senza rovinare il resto del sistema. Al termine, digita exit o premi ctrl-D
Linuxbrew è un altro gestore di pacchetti non root per Linux (basato sul famoso sistema di gestione dei pacchetti Homebrew per OS X) che viene compilato dal sorgente e mantiene i binari nella directory home.
Citando i documenti, le funzionalità di Linuxbrew sono:
Il prefisso Gentoo fa esattamente quello che vuoi.
Installa tutti i pacchetti in una directory specificata. Nessun accesso root richiesto. Se vuoi sbarazzartene, rimuovi la directory di base.
PS: Questo non funziona su Ubuntu> = 11.04 o su qualsiasi altro derivato Debian con Multiarch.
Proprio come un'aggiunta minore all'opzione di compilarlo, c'è l'opzione a metà strada di compilare in un pacchetto con un'opzione di prefisso diversa al momento della compilazione (con "checkinstall" o forse qualche altro metodo). Il vantaggio è che il pacchetto apparirà su gestori di pacchetti come aptitude o synaptic.
Oltre a ciò penso che in alcuni casi possa essere possibile scaricare il .deb effettivo e forzare un prefisso diverso tramite l'installazione di dpkg, ma penso che non sia qualcosa che può essere fatto con qualsiasi pacchetto casuale, ma devono essere stati compilati con alcune variabili per la loro posizione (anziché il prefisso esplicito letterale) che avresti esportato prima dell'installazione. Non so nulla della procedura, google per "dpkg instdir prefix".
Puoi usare fakechroot - dai un'occhiata alla demo sul loro sito web.
Roboless GoboLinux può fare esattamente quello che stai chiedendo: gestore di pacchetti, senza privilegi elevati, nella tua home directory. Spero che tu sappia cosa stai facendo; rootless non è la modalità di installazione di Gobo più ben mantenuta e quando lo usavo qualche anno fa richiedeva alcune modifiche poiché lo script di installazione era un po 'obsoleto rispetto ad altre modifiche a Gobo.
C'è anche klik che riconfeziona parecchi .debs, può installare pacchetti nella tua home directory e non richiede alcun privilegio di root per funzionare ... ma l'installazione iniziale richiede root.
Di solito ricevo le fonti e controllo un file come "INSTALL". Di solito ci sono istruzioni da fare ./configure --prefix=somedir. Quindi devi aggiungere somedir/binal tuo percorso.
No, non penso che tu possa.
Il meglio che posso pensare in questo momento è usare apt-get sourcee compilare il pacchetto. Forse potresti in qualche modo modificare la procedura (che può essere più o meno automatizzata) per installare i pacchetti nella tua casa.
Un altro è quello di utilizzare dpkg -Xper estrarlo in una directory di vostra scelta.
Ci sono pochissimi casi in cui dovresti installare pacchetti nella tua cartella home.
Tuttavia, è possibile compilare e installare software sul computer locale. Basta decomprimere, quindi configurare con ./configure --prefix=$HOME/localo un'altra directory. È quindi possibile makee make installnormalmente. Questo compilerà e installerà quel programma ~/local/, ad esempio il programma che eseguirai ~/local/bin/programmname.
Dalla mia esperienza, non esiste un modo semplice per usare i pacchetti DEB esistenti da installare in un'altra directory che non è un ambiente chroot . Gli strumenti di installazione di Debian / Ubuntu dpkg / aptitude / dselect richiedono tutti i privilegi di root per funzionare correttamente.
Ora dato il DEB di origine è possibile modificare il file Debian / rules per fare in modo che il pacchetto venga compilato e installato in un albero di directory diverso, ma non si utilizzano i pacchetti binari già disponibili.
Come altri hanno già detto, puoi usare debootstrap e creare facilmente un ambiente chroot, cosa che ho fatto in passato per avere un ambiente a 32 bit su un host a 64 bit, ma ciò richiede l'installazione di un chroot con almeno i pacchetti di base duplicati. Se hai lo spazio e questa è una soluzione praticabile, puoi accoppiarla dchrooto, ancora meglio schroot, per consentire una facile esecuzione delle applicazioni installate nell'ambiente chroot.
Ho difficoltà a immaginare come funzionerebbe con i repository ufficiali di una distribuzione. Come dovrebbe risolvere le dipendenze? Dal sistema o dalle tue home directory? Cosa succede se trova versioni diverse in entrambi?
Il meglio che mi viene in mente sarebbe un ambiente chroot come fanno le persone per applicazioni a 32 bit su sistemi a 64 bit. È più sovraccarico di come si chiamerebbe debootstrap nel chroot, ma con un po 'di symlinking , divertente script shell wrapper, potrebbe fare quello che vuoi.
Sto ancora lavorando al problema, ma debootstrap fondamentalmente ciò di cui hai bisogno e dovrebbe funzionare con fakeroot. debootstrap è solo un mucchio di script di shell, quindi lo sto separando per vedere cosa lo fa spuntare. La parte difficile sarà disinstallare i file una volta installati.
Sfortunatamente non ho sentito parlare di alcuna distribuzione che fornisca qualcosa del genere (anche se sono sicuro che sarebbe super popolare). Potresti essere in grado di imitare la distro basata su rpm però ... Non l'ho provato, ma potresti essere in grado di creare un database rpm basato sull'utente e quindi installare gli rpm nel database utente.
Prova a configurare una nuova distribuzione basata sugli utenti con:
rpm --initdb --dbpath DIRECTORY
Quindi ci sono diverse opzioni che possono aiutare:
--prefix--relocateHo una soluzione che ho usato con successo per installare una GRANDE raccolta di pacchetti software cooperanti su un server Debian della scuola, dove non ho alcun accesso root (nemmeno per l'installazione di un altro gestore di pacchetti). Non utilizza deboostrapné alcun gestore di pacchetti.
Il metodo è parzialmente manuale, ma ho fatto del mio meglio per renderlo conveniente.
Usa questo script che ho chiamato install(non dimenticarlo chmod +x):
#!/bin/bash
# PREFIX is the installation root, i.e. a directory you have write access to
PREFIX=$HOME
# unpack the archive to $PREFIX
ar p "$1" data.tar.xz | tar xJ -C $PREFIX
# go through all unpacked text files and search for occurences of /usr/...
# we're gonna replace some of them with $PREFIX/usr
files=$(dpkg --contents $1 | grep '^-' | awk '{print $6}' | sed 's/^..//' | sort | uniq)
for f in $files; do
file="${PREFIX}${f}"
if grep -Iq . "$file"; then
if grep -q '/usr' "$file"; then
# interactively ask for each occurence, if it should be replaced
vim -c '%s#/usr#'$PREFIX'/usr#gc' -c 'wq' "$file"
fi
else
echo "Leaving binary file $file unmodified"
fi
done
Quindi di solito scarico prima un file deb usando apt-get download package_name. Quindi corro ./install package_name_blabla.debe decido manualmente ogni ricorrenza /usrnei file decompressi, se deve essere sostituito $PREFIX/usro meno.
Questa decisione dipende completamente da quali pacchetti sono installati dal sistema e quali sono installati usando questo metodo. Di solito, ad esempio, i file pkg-config necessitano di questa sostituzione, mentre le linee shebang come #!/usr/bin/perlno. La regola generale è che il percorso risultante dovrebbe puntare a un file esistente.
Con i pacchetti installati in questo modo, ovviamente devi in qualche modo parlarne agli altri programmi. Ciò può essere realizzato aggiungendo i valori corretti LD_LIBRARY_PATH, PATH, PYTHONPATH, PKG_CONFIG_PATH, CMAKE_MODULES_PATH, CMAKE_PREFIX_PATHetc.
C'è un avvertimento in questo approccio, che le dipendenze non vengono scaricate / installate automaticamente; devi tenerne traccia manualmente.
Inoltre APT ovviamente non conosce questi pacchetti, quindi li mostrerà per sempre come mancanti. Ma questo ha senso: chi vorrebbe installare un'app a livello di sistema che dipende dall'installazione di un utente.
Se si desidera disinstallare un programma, è possibile elencare il contenuto dell'archivio deb utilizzando ar p "$1" data.tar.xz | tar tJe quindi eliminare tutti questi file da PREFIX.