[SOLVED] Instalowanie w /opt

[Nju]

Zastanawiam się, czy moża instalować coś w /tmp albo /opt jako zwykły uzytkownik? Znaczy, czy mogę sobie nadać prawa do tych katalogów, czy jednak zostać przy instalowaniu wszystkiego w /home? Przez „wszystko” mam na myśli np. IDE, albo jakieś trzecie programy do menadżerowania modułami w pythonie(anaconda).

[napcok]

Ja od lat mam taki nawyk, że zmieniam właściciela /opt na zwykłego usera i trzymam tam różne dane, albo instaluje różne rzeczy, których nie ma w repozytoriach (choć to zdarza się niezmiernie rzadko). Myślę, że to nie jest zły pomysł :)

Edit.
/opt mam zawsze jako oddzielną partycję – można łatwo ją „współdzielić” z innymi zainstalowanymi systemami.

Appki pod konsolę | czasem piszę tutaj | Pomóż sobie i innym - mądrze zadawaj pytania

[pavbaranov]

Wszystko można, tylko…
1. Instalacja w /tmp – jeśli robione jest to tak samo jak w Archu (bo już nie pamiętam), to bez w tym zakresie instalacja czegokolwiek w /tmp mija się z celem, albowiem /tmp to… część RAM.
2. Instalacja w /opt – oczywiście jest możliwa. Przeanalizuj sobie np. paczkę masterpdfeditor – to akurat jest konwersja z deb, ale tak się robi takie paczki. Uprawnień do katalogu nie musisz zmieniać i… myślę, że lepiej, by tak zostało, bo paczki, które tam są instalowane nie będą pluły błędu uprawnień.
3. Znów – jeśli Manjaro niczego tu nie zmieniło – to domyślnym katalogiem na instalację lokalnych (tj. dla danego użytkownika) programów jest ~/.bin (ew. ~/.binary), które są widoczne dla systemu. Tu w istocie uprawnienia są takie same jak dla całego katalogu użytkownika.

[Nju]

2. No własnie jak zainstalowałem sobie Anaconde(python) w /opt to nie mogę jej używać :P Bo jako zwykły user nie mam praw, jako root nie widzi polecenia „conda”. A nie chce tego w swoim katalogu instalować bo robi się śmietnik przy większej ilości programów.

3. Nie mam takich katalogów

[pavbaranov]

ad. 2: Jak instalowałeś tę anakondę? W systemie masz instalować wszystko poprzez pacmana (czyli musisz mieć PKGBUILD). W AUR są anaconda i anaconda2 (nie wiem czym się różnią), oba instalują się do /opt/anakonda(-2). Jeśli instalowałeś z AUR, a niczego nie zmieniałeś w uprawnieniach do /opt, to – o ile problem dotyczy braku możliwości uruchamiania – to leży w PKGBUILD (choć go nie widzę). Jeśli instalowałeś w inny sposób – zainstaluj tak jak wszystko w Archu (Manjaro) winno być instalowane, czyli przez pacmana. W tym przypadku z AUR (UWAGA – musisz mieć sporo RAM na to lub zbudować w innej lokalizacji niż tmpfs).
Jeśli program jest „niewidoczny” to sprawdź sobie ustawienia środowiska, czy w ogóle w PATH masz /opt. Inna sprawa, że obie paczki tworzone na podstawie PKGBUILDów z AUR nie dostarczają pliku *.desktop, który winien w nich być (błąd PKGBUILD do zgłoszenia). Możesz sobie taki plik napisać we własnym zakresie. Dla „schematu” możesz wykorzystać jakikolwiek inny plik typu *.desktop uruchamiający jakikolwiek inny program. Najlepiej też dołączyć go do budowanej paczki, tak by pacman widział ten plik jako należący do określonej paczki.
ad. 3: Skoro nie masz takiego katalogu (a nie jest on domyślnie tworzony), trzeba go stworzyć. Być może nie masz też zdefiniowanego ~/bin w PATH – wowczas trzeba sobie dodać wg któregoś z tych przepisów.

EDIT:
Ok, zbudowałem tę anacondę. W lokalizacji /opt/anaconda/bin jest mnóstwo wykonywalnych plików pythona. Jeśli wszystkie one muszą być dostępne jako wykonywalne z poziomu systemu (a nie programu), to powinieneś dodać sobie zmienną środowiskową PATH=/opt/anaconda/bin do systemu. Jeśli tylko conda, to możesz stworzyć plik anaconda.desktop, w którym wpiszesz (to nie cały plik *.desktop):

Exec=/opt/anaconda/bin/conda
Icon=/opt/anaconda/share/pixmaps/spyder3.png (o ile to jest ikona dla tego programu)

Reszta pliku anaconda.desktop – wg Twojego uznania (oczywiście w ramach „schematu”). Plik anaconda.desktop winien być umieszczony w /usr/share/applications/. Jeśli chcesz to zrobić prawidłowo (czyli by był instalowany przez paczkę, to po ściągnięciu tarballa, powinieneś dokonać edycji PKGBUILD, dodać anakonda.desktop (który sam stworzysz) do pola source oraz w sekcji package dodać:
install -D -m644 $srcdir/anaconda.desktop "${pkgdir}/usr/share/applications/"
(powinno być prawidłowo, ale 100% nie daję).

[Nju]

Anaconde instalowałem przez ściągnięcie instalki ze strony a potem poleceniem bash Anaconda. Przy instalacji sam program od razu dodaje się do PATH, więc ja nic nie muszę robić.
Zrobiłem /opt z prawami 777 bo zainstalowałem tam też PyCharm, którego Pacman nie ma i inne programy które mam dla swojego użytku.
Twoja droga może i bezpieczniejsza, ale dłuższa i zawiła. A wydaje mi się, że akurat /opt z taki mi prawami nie powinien mi sprawiać dużych problemów

[pavbaranov]

Nju napisał(a):

zainstalowałem tam też PyCharm, którego Pacman nie ma

Pacman niczego nie ma :) Niemniej jednak w AUR są następujące programy pycharm:

aur/pycharm-community-eap 2016.2.162.1236.15-1 (2 głosów) [nieaktualny]
    Powerful Python and Django IDE, Early Access Program (EAP) build. Professional edition.
aur/pycharm-edu 3.5.0-1 (3 głosów)
    Free, Easy & Professional Tool to Learn Programming with Python
aur/pycharm-community 2017.1-1 (306 głosów)
    Powerful Python and Django IDE. Community edition.
aur/pycharm-eap 2:2017.1.0.171.3780.115-1 (21 głosów)
    Powerful Python and Django IDE, Early Access Program (EAP) build. Professional edition.
aur/pycharm-professional 2017.1.0-2 (144 głosów)
    Powerful Python and Django IDE. Professional edition.

Generalnie to jedna rada – jeśli nie chcesz prędzej czy później obudzić się z rozwalonym systemem, to instaluj programy przez menedżera pakietów, jaki udostępnia Ci system (pacman). Oczywiście Twój system – możesz z nim robić co chcesz, ale droga, jaką obrałeś nie jest sensowna.

[Nju]

OK, więc mam po prostu wgrać to repozytorium i mogę sobie szukać w nim paczek? BTW. Widzę właśnie te wersje pycharm które pokazałeś, ale mam licencje do 2016, a nie 2017

[pavbaranov]

AUR to nie jest repozytorium w klasycznym, linuksowym znaczeniu. To są „przepisy” na budowanie paczek – głównie PKGBUILDy, czasem jeszcze jakieś pliki towarzyszące. W Manjaro masz albo pamac albo octopi oraz yaourt. Jedno i drugie obsługuje AUR. Po zaznaczeniu w nich odpowiedniej opcji (tj. przeszukiwania również AUR) buduje paczki na podstawie owych „przepisów” w AUR.
Problemem może być w zasadzie wyłącznie budowanie dużych paczek (a w zasadzie nawet nie tylko dużych, ale z dużych plików źródłowych), albowiem domyślnie makepkg buduje to w tmpfs, które – znów domyślnie – wykorzystuje 1/2 dostępnego RAM.
Zob.: wiki Archa i nieco na moim blogu.

Z licencją – nie bardzo rozumiem. Jeśli masz licencję „na 2017” to korzystaj. Jedna, jedyna przestarzała paczka, to pycharm-community-eap. Z tego co widzę, to po 2016.2 build 162.1236.15 była jeszcze 2016.3 build 163.15188.4, a teraz jest 2017.1. Ta ostatnia (i poprzednie) ma 2 wersje: community oraz professional. Na którą masz licencję/potrzebujesz, to postaramy się PKGBUILD dla niej zrobić.

[Nju]

Miałeś racje, strasznie fajnie się tego używa(yaourt), nie ma też problemu z żadnymi prawami, a instaluje mi w /opt tak jak chciałem. Podoba mi się. Dzięki za pomoc :)

[pavbaranov]

Teraz zerknij na tabelę tzw. AUR helperów. Wprawdzie yaourt jest bodaj najpopularniejszym, ale są lepsze. Wybrałbym taki, który ma wszystkie „Yes” – np. pacaur (bo również popularny), czy trizen.
Zerknij sobie jeszcze na te dwa teksty – mam nadzieję, że coś Ci się więcej wyjaśni. Osobiście większość programów, które kompiluję robię wg tej drugiej „zasady”.

[Autor]

Posty