Obecna, przejściowa sytuacja związana z procesem przeportowania aplikacji, które korzystają do tej pory z bibliotek KDE4 i/lub frameworka Qt4 powoduje, że w repozytoriach Archa (i Manjaro) znajdują się aplikacje zgodne z wersjami publikowanymi przez tzw. upstream. Niemniej jednak istnieje duża ilość aplikacji, które albo można, korzystając z tych samych źródeł kompilować zarówno jako aplikacje oparte o Qt4, jak i Qt5, albo można kompilować je ze źródeł dostępnych w GIT (SVN) i również przeprowadzić kompilację opierając się o Qt5 i/lub KF5. Niektóre osoby korzystają z takich rozwiązań używając do tego PKGBUILDów różnego pochodzenia, choćby zamieszczanych w POLAUR.
Skonstruowanie sobie systemu w oparciu o te, nieoficjalne w stosunku do repozytoriów Archa, czy Manjaro, aplikacje, powoduje, że kiedy pojawią się nowe, oficjalne już wersje naszych aplikacji, to:
1. pacman nie zauważy, że pojawiła się taka aplikacja,
2. próba instalacji jej przez pacmana odręcznie, spowoduje, że pacman odmówi instalacji.
Przyczyną pierwszego jest inne nazewnictwo paczek, które nie jest uwzględnione w sekcji conflicts PKGBUILDów. Najczęściej bowiem, paczki oficjalne nazywają się tak jak nazwali swe aplikacje osoby je projektujące (zgodnie z założeniami Archa tak winno być, choć nie jest to przestrzegane w 100%), podczas gdy paczki z AUR (POLAUR) mają zwykle nazwy wyglądające w następujący sposób:
nazwa_aplikacji-frameworks-git
nazwa_aplikacji-qt5-git
i zbliżone (np. w miejscu git może być svn, albo w miejscu qt5, czy frameworks spotykane jest również kf5).
Zwykle, opiekunowie paczek w repozytoriach, zapewniają "konflikt" między paczkami o nazwach nazwa_paczki i nazwa_paczki-git, bardzo rzadko jednak zdarza się, by oficjalne paczki również zapewniały taki konflikt z paczkami o nazwach wymienionych wyżej. Dlatego też istnieje prawdopodobieństwo graniczące z pewnością, że kiedy dolphin wraz z wydaniem KDE Applications 15.08 pojawi się w wersji zbudowanej w oparciu o KF5, to instalacja jego doprowadzi do odinstalowania obecnego dolphin-git i zainstalowania dolphin. Inna sprawa, czy automatyczna aktualizacja systemu również zauważy, że w systemie znajduje się dolphin-git, który wymaga aktualizacji do dolphin. Raczej nie jest to możliwe.
Przyczyna drugiego z "błędów" leży również w nazewnictwie oraz zawartości sekcji conflicts w PKGBUILD. W przeciwieństwie do opisanego wyżej dolphina, istnieje znikome prawdopodobieństwo, by np. paczka skanlite oparta o KF5 wiedziała, że ma dokonać odinstalowania paczek skanlite-frameworks-git i libksane-frameworks-git i w to miejsce zainstalować ich "stabilne" odpowiedniki oparte o KF5/Qt5. Próba instalacji nowej wersji zakończy się zatem stwierdzeniem przez pacmana, że jakieś pliki są już w systemie i nie można dokonać instalacji.
Teraz to co najważniejsze rozwiązanie "problemu".
Po pierwsze, na tyle, na ile się da, będę starał się informować o tym, jakie nowe paczki zostają przeportowane do Qt5/KF5. W naszych "Ogłoszeniach" na pewno pojawią się informacje o kolejnych KDE Applications wraz ze wskazaniem kolejnych, przeportowanych paczek. Podobnie starał się będę umieszczać informacje o tych aplikacjach, które albo zyskały swoje oficjalne wersje oparte o Qt5 rozwijane równolegle do Qt4 (to etap wysoce przejściowy i w zasadzie z końcem 2015 r. paczki oparte o Qt4 winny zanikać), albo które weszły w miejsce dotychczasowych.
W przypadku, gdy używamy ich odpowiedników budowanych z AUR, POLAUR, czy czegokolwiek innego, najlepszym rozwiązaniem będzie przyjęcie następującej kolejności działań.
1. Próbujemy aktualizacji systemu:
# pacman -Syu
2. Jeśli nie zainstalują się paczki w nowych, pochodzących z oficjalnych repozytoriów wersjach, znajdujemy ich nazwę (w dowolny sposób, najłatwiej jest wykorzystując yaourt bądź pkgbrowser) i próbujemy instalować taką paczkę:
# pacman -Sy <nazwa_paczki>
3. Jeśli operacja się powiedzie, ok, jeśli dostrzeżemy błąd polegający na odmowie instalacji z uwagi na konfliktujące pliki, to:
a) jeśli znamy nazwę paczki, próbujemy ją odinstalować i zainstalować z repozytorium:
# pacman -R <nazwa_naszej_paczki> && pacman -Sy <nazwa_paczki>Całkiem możliwe, że w dalszym ciągu będzie to niemożliwe, bo jakieś zależności nadal nie puszczą. Nie chcę jednak zalecać instalacji, czy odinstalowania paczek z wykorzystaniem czy to sposobów siłowych, czy też wraz z zależnościami bądź z ich pominięciem. Jeśli znacie te rozwiązania, to robicie to na własną odpowiedzialność.
b) jeśli nie znamy nazwy paczki, wykonujemy:
# pacman -Qo <nazwa_konfliktującego_pliku>Ów konfliktujący plik zobaczymy po próbie instalacji, przy jej odmowie. Wykonując powyższe polecenie otrzymamy informację o tym, jaka paczka jest właścicielem (czyli zainstalowała) nam ten konfliktujący plik. Musimy ją teraz odinstalować i zainstalować to, co potrzebujemy.
I tak do skutku.
