Czy jest jakiś sposób, aby APT zainstalował pakiety w moim katalogu domowym?
Nie chcę wprowadzać zmian w całym systemie.
Alternatywnie, czy są jakieś menedżery pakietów linuksowych oparte na katalogu macierzystym?
Odpowiedzi:
Dpkg nie ma funkcji --relocate, którą ma RPM. Warto jednak zastanowić się, ile pakietów RPM obsługuje tę funkcję. Zasadniczo nie da się tego zrobić.
Możesz użyć chroota, jeśli chcesz coś przetestować przed zainstalowaniem go globalnie w systemie. Aby to zrobić, musisz mieć dostęp do roota. Pierwszą rzeczą do zrobienia jest stworzenie podstawowego chroota:
# debootstrap lenny lenny-chroot
To tworzy chroota Lenny'ego w lenny-chrootkatalogu.
Teraz możemy wejść do chroot:
# chroot lenny-chroot
Teraz możemy robić, co tylko zechcemy i instalować wszystko, co nie zepsuje reszty systemu. Kiedy skończysz, wpisz exit lub naciśnij ctrl-D
Linuxbrew to kolejny inny niż root menedżer pakietów dla systemu Linux (oparty na popularnym systemie zarządzania pakietami Homebrew dla systemu OS X), który kompiluje się ze źródła i przechowuje pliki binarne w katalogu domowym.
Cytując dokumenty, funkcje Linuxbrew to:
Prefiks Gentoo robi dokładnie to, co chcesz.
Instaluje wszystkie pakiety w określonym katalogu. Nie wymaga dostępu do roota. Jeśli chcesz się go pozbyć, po prostu usuń katalog podstawowy.
PS: To nie działa na Ubuntu> = 11.04, ani na żadnej innej pochodnej Debiana z Multiarch.
Podobnie jak niewielki dodatek do opcji kompilacji, istnieje opcja połowy kompilacji do pakietu z inną opcją prefiksu w czasie kompilacji (z „checkinstall” lub inną metodą). Zaletą jest to, że pakiet pojawi się na menedżerach pakietów, takich jak aptitude lub synaptic.
Poza tym myślę, że w niektórych przypadkach może być możliwe pobranie aktualnego pliku .deb i wymuszenie innego prefiksu przez instalację dpkg, ale myślę, że nie jest to coś, co można zrobić z dowolnym losowym pakietem, ale trzeba je skompilować z jakąś zmienną dla ich lokalizacji (zamiast dosłownego wyraźnego przedrostka), którą wyeksportowałeś przed instalacją. Nic nie wiem o tej procedurze, google dla „dpkg instdir prefix”.
Możesz użyć fakechroot - spójrz na wersję demo na ich stronie internetowej.
Bezrootowy GoboLinux może robić dokładnie to, o co prosisz: menedżer pakietów, bez podwyższonych uprawnień, we własnym katalogu domowym. Mam nadzieję, że wiesz, co robisz; rootless nie jest najlepiej utrzymanym trybem instalacji Gobo, a kiedy go używałem kilka lat temu, wymagało to kilku poprawek, ponieważ skrypt instalacyjny był nieco nieaktualny w stosunku do innych zmian w Gobo.
Jest też kliknięcie, które przepakowuje sporo .debs, może instalować pakiety w twoim katalogu domowym i nie wymaga uprawnień roota do działania ... ale początkowa konfiguracja wymaga roota.
Zwykle pobieram źródła i sprawdzam plik typu „INSTALUJ”. Zwykle są instrukcje do zrobienia ./configure --prefix=somedir. Następnie musisz dodać somedir/bindo swojej ścieżki.
Nie, nie sądzę, że możesz.
Najlepsze, co mogę teraz pomyśleć, to użyć apt-get sourcei skompilować twój pakiet. Może uda ci się jakoś ulepszyć procedurę (która może być mniej lub bardziej zautomatyzowana), aby zainstalować pakiety w domu.
Innym jest dpkg -Xwypakowanie go do wybranego katalogu.
Jest bardzo niewiele przypadków, w których trzeba zainstalować pakiety w folderze domowym.
Można jednak skompilować i zainstalować oprogramowanie na komputerze lokalnym. Po prostu rozpakuj, a następnie skonfiguruj za pomocą ./configure --prefix=$HOME/locallub innego katalogu. Możesz wtedy makei make installjak zwykle. Spowoduje to kompilację i instalację tego programu ~/local/, np. Program, który wykonasz będzie w ~/local/bin/programmname.
Z własnego doświadczenia nie ma łatwego sposobu na użycie istniejących pakietów DEB do zainstalowania w innym katalogu, który nie jest środowiskiem chroot . Wszystkie narzędzia instalacyjne Debian / Ubuntu dpkg / aptitude / dselect wymagają do prawidłowego działania uprawnień administratora.
Biorąc teraz pod uwagę źródłowy DEB, możesz zmodyfikować plik Debian / rules, aby pakiet został skompilowany i zainstalowany w innym drzewie katalogów, ale wtedy nie używasz już dostępnych pakietów binarnych.
Jak wspomnieli inni, możesz użyć debootstrap i łatwo zbudować środowisko chroot, co zrobiłem w przeszłości, aby mieć 32-bitowe środowisko na 64-bitowym hoście, ale wymaga to zainstalowania chroot z przynajmniej zduplikowanymi pakietami podstawowymi. Jeśli masz wystarczająco dużo miejsca i jest to realne rozwiązanie, możesz je połączyć dchroot, a nawet lepiej schroot, aby umożliwić łatwe uruchamianie aplikacji zainstalowanych w środowisku chroot.
Mam problem z wyobrażeniem sobie, jak to by działało z oficjalnymi repozytoriami z dystrybucji. Jak powinien rozwiązać zależności? Z systemu czy z domowych katalogów? Co jeśli znajdzie różne wersje w obu?
Najlepsze, co mogę wymyślić, to środowisko chroot, takie jak ludzie dla 32-bitowych aplikacji na 64-bitowych systemach. Jest to bardziej narzut, ponieważ wywołujesz debootstrap w chroocie , ale przy odrobinie symlinkowania i zabawnym skrypcie otoki powłoki, może zrobić to, co chcesz.
Nadal pracuję nad tym problemem, ale debootstrap w zasadzie to, czego potrzebujesz i powinien działać z Fakeroot. debootstrap to tylko kilka skryptów powłoki, więc rozkładam go, aby zobaczyć, co sprawia, że tyka. Trudność polega na odinstalowaniu plików po ich zainstalowaniu.
Niestety nie słyszałem o żadnej dystrybucji oferującej coś takiego (chociaż jestem pewien, że byłby bardzo popularny). Możesz być w stanie naśladować dystrybucję opartą na rpm ... Nie próbowałem tego, ale możesz być w stanie zbudować bazę danych rpm opartą na użytkownikach, a następnie zainstalować rpm w bazie danych użytkowników.
Spróbuj skonfigurować nową dystrybucję użytkownika za pomocą:
rpm --initdb --dbpath DIRECTORY
Istnieje kilka opcji, które mogą pomóc:
--prefix--relocateMam rozwiązanie, którego udało mi się zainstalować, aby zainstalować DUŻĄ kolekcję współpracujących pakietów oprogramowania na szkolnym serwerze Debian, na którym w ogóle nie mam dostępu do roota (nawet w przypadku instalowania innego menedżera pakietów). Nie używa deboostrapani żadnego menedżera pakietów.
Ta metoda jest częściowo ręczna, ale zrobiłem wszystko, aby była wygodna.
Używa skryptu, który wywołałem install(nie zapomnij 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
Zwykle więc najpierw pobieram plik deb za pomocą apt-get download package_name. Następnie uruchamiam ./install package_name_blabla.debi ręcznie decyduję o każdym wystąpieniu /usrrozpakowanych plików, czy należy je zastąpić, $PREFIX/usrczy nie.
Ta decyzja całkowicie zależy od tego, które pakiety są instalowane w systemie, a które są instalowane za pomocą tej metody. Zwykle np. Pliki pkg-config wymagają tego podstawienia, podczas gdy linie shebang #!/usr/bin/perlnie wymagają . Ogólna zasada jest taka, że wynikowa ścieżka powinna wskazywać na istniejący plik.
Przy tak zainstalowanych pakietach, oczywiście musisz w jakiś sposób powiedzieć o nich innym programom. Można to osiągnąć przez dodanie do wartości prawidłowych LD_LIBRARY_PATH, PATH, PYTHONPATH, PKG_CONFIG_PATH, CMAKE_MODULES_PATH, CMAKE_PREFIX_PATHitd.
Jest takie zastrzeżenie, że zależności nie są pobierane / instalowane automatycznie; musisz je śledzić ręcznie.
APT oczywiście nie wie o tych pakietach, więc na zawsze pokaże je jako brakujące. Ma to jednak sens - kto chciałby zainstalować aplikację systemową, która zależy od instalacji użytkownika.
Jeśli chcesz odinstalować program, możesz wyświetlić zawartość archiwum deb przy użyciu, ar p "$1" data.tar.xz | tar tJa następnie usunąć wszystkie te pliki z PREFIX.