Czy jest jakiś sposób, aby APT zainstalował pakiety w moim katalogu domowym?

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?

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:

• Może zainstalować oprogramowanie w katalogu domowym, więc nie wymaga sudo
• Zainstaluj oprogramowanie spakowane przez natywną dystrybucję
• Zainstaluj aktualne wersje oprogramowania, gdy natywna dystrybucja jest stara
• Użyj tego samego menedżera pakietów do zarządzania komputerami Mac i Linux

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.

• Zobacz post autora .
• Szczegółowe przypadki użycia
• Informacje o instalacji (?)
• Strona projektu

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
• --relocate

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