Na ostatnie pytanie - nie - nie stanie się krzywda ani Tobie, ani systemowi, ani komputerowi. Pamac(-aur/classic) to jest swego rodzaju nakładka na pacman (w zasadzie to zdaje się, że na libalpm), która umożliwia zarządzanie tak paczkami z repozytorium (czyli jest w tym zakresie odpowiednikiem pacman), jak i AUR. Dodatkowo oferuje GUI.
Jeśli nie jest dla Ciebie istotne GUI, nie używasz AUR, to po prostu pozostań przy pacman lub... zainstaluj sobie pak.
Kilka uwag nt. pak.
Pak (ten z POLAUR, bo pojawiła się również paczka o takiej nazwie w AUR, a to 2 różne rzeczy) to również nakładka na pacmana, rozszerzająca jego możliwości m.in. o AUR. W zakresie obsługi repozytoriów pak po prostu korzysta z pacmana. Wywołanie - powiedzmy
pak -S paczka dokonuje wywołania pacmana ze składnią:
pacman -Syu paczka. Pak nie zawiera żadnych "sztuczek", nie korzysta z nieudokumentowanych rzeczy w libalpm. Teraz o zaletach i wadach pak (przy założeniu, że zainstalujesz zależności opcjonalne pak, które znacznie rozszerzają jego funkcjonalność).
Zalety (to m.in.):
1. Instalowanie czegokolwiek przez pak
nigdy nie doprowadzi do tzw. częściowej aktualizacji systemu. Wywołanie instalacji paczki za pomocą pak spowoduje zaktualizowanie systemu, a następnie zainstalowanie paczki. Podobnie pak zachowuje się w przypadku instalacji (czyt. budowania) czegokolwiek z AUR i POLAUR.
2. Pak - jak już widać - obsługuje także AUR i POLAUR. Budując paczki z nich dokonuje dokładnie tego samego, co użytkownik zrobić by musiał, gdyby ręcznie budował paczkę z AUR: klonuje repozytorium danego programu, wchodzi do pobranego katalogu, wywołuje makepkg budując paczkę, następnie pozwala na instalację jej i usunięcie zbędnych zależności, jak również wyczyszczenie katalogów budujących paczkę. Brak tu jakichkolwiek sztuczek - krok po kroku wywołuje instrukcje. Nadto umożliwia walidację tak PKGBUILDu jak i zbudowanej paczki (przez namcap).
3. Umożliwia aktualizacje tzw. mirrorów dla pacmana (przez reflector).
4. Umożliwia ściągnięcie PKGBUILDów tak dla paczek z repo (przez abs), jak i z AUR.
5. Zachowuje składnię pacmana w wysokim stopniu, choć np.
pak -S paczka znaczy
pacman -Syu paczka.
6. Umożliwia przeszukiwanie tak AUR, jak i POLAUR. O repo nie wspomnę, to oczywiste.
7. Umożliwia łatwe uzyskanie informacji o zmianach w zakresie paczek zainstalowanych lokalnie.
8. Umożliwia uzyskanie informacji, czy paczki z CVS (np. te, z "git" na końcu) mogą zostać zaktualizowane do nowszych wersji skutkiem pojawienia się nowych źródeł.
9. Umożliwia informację o dostępnych aktualizacjach paczek ze wszystkich źródeł obsługiwanych przez pak.
10. Podaje informacje o tzw. niescalonych plikach (chodzi o paczki, które dostarczają plików - najczęściej konfiguracyjnych - np. z pacnew w nazwie).
11. Umożliwia przeczyszczenie systemu z kopii odinstalowanych paczek.
12. Pak nigdy nie zawiesi swego działania ze względu na nową wersję pacman, jaka się pojawia w repo. Po prostu skorzysta z nowszej wersji. (Sytuacja z jaką się spotkałeś z pamac nigdy nie będzie miała miejsca).
I jeszcze kilka innych rzeczy pewnie by się znalazło.
Wady:
1. Budując paczkę z AUR, która wymaga wcześniejszego zbudowania paczki również z AUR nie uczyni tego, a jedynie poinformuje o konieczności wcześniejszego zbudowania paczek.
2. W sumie nie wada, albowiem doszliśmy do wniosku, że szkoda robić coś, co już jest zrobione - korzysta niekiedy z innych paczek aby osiągnąć pełną funkcjonalność.
Jeśli pragniesz pak mieć, to musisz wywołać następującą linię (podaję dla pak, albowiem jest jeszcze pak-git, ale to jest w zasadzie wersja dla Damiana i dla mnie
:
sudo pacman -S wget && mkdir pak && cd pak && wget https://raw.githubusercontent.com/polaur/new-branded/master/pak/PKGBUILD && wget https://raw.githubusercontent.com/polaur/new-branded/master/pak/CHANGELOG && makepkg -sircKatalog pak możesz wykasować, gdyż po zbudowaniu w ten sposób pak będziesz mógł jego aktualizacje wykonywać za jego pomocą.
