Pierwsza próba zrobienia czegoś naprawdę pożytecznego (rozwiązywanie zależnośći w PackageKit)

Zacznijmy od tego, czemu to tworzę.

PackageKit od samego początku nie ma rozwiązywania zależności. Spotkałem się z wieloma opiniami, że z użyciem graficznego menedżera paczek, nie można wszystkiego w systemach GNU/Linux zainstalować. Głównym zarzutem był brak możliwości rozwiązania zależności. No, cóż... Problem rozwiązano dawno temu. Mogłem rozwiązywać zależności w Yast odkąd pamiętam. Jednak sklepy z aplikacjami, jak gnome-software czy plasma-discover nie dostarczają tej opcji. Innym problemem jest brak możliwości zaktualizowania systemu, poprzez aplet aktualizacji, jeśli w nim namieszaliśmy.

Jak postanowiłem podejść do problemu

Stworzyłem specjalnego daemona, który zapamiętuje identyfikator DBus na szynie systemowej procesu, który się do niego zgłosi. Daemon ten pobiera też jego identyfikator sesji (z drzewa /proc). Kiedy PackageKit dostanie żądanie dokonania transakcji, podaje temu daemonowi identyfikator DBus swego klienta. Daemon pobiera identyfikator sesji klienta PackageKit i porównuje go z identyfikatorami sesji zgłoszonych procesów. Na końcu zwracamy identyfikator DBus zgłoszonego procesu, który pracuje w odpowiedniej sesji. PackageKit następnie, korzystając z biblioteki klienta Bonsole, tworzy UI i odpowiada na żądania.

Co musi być zrobione, i jakie są obecnie problemy

Przede wszystkim, to nie wiem, jak rozwiązać problem z interaktywnością. Mam parę pamysłów, ale muszę je przemyśleć. Chodzi o to, że jakiś skrypt może korzystać z np. pkcon. Mogę oczywiście stworzyć listę sklepów z aplikacjami (nazwy programów) i wykluczyć pkcon, ale wtedy bym musiał stworzyć nową konsolową apkę do komunikacji z PackageKit. Mogę też dodać pole „interaktywne” do obiektu transakcji, ale wtedy wymagane byłby zmiany w klientach, jak plasma-discover czy gnome-software. Chyba najlepszym wyjściem byłoby połączenie obu pomysłów, czyli lista dozwolonych klientów + możliwość wymuszenia trybu interaktywnego przez zmianę wartości pola poprzez DBus. Wtedy wystarczyłoby tylko do pkcon dodać odpowiednią flagę. Obecnie realizowane to jest w ten sposób, że gdy klient zażąda wymuszenia ukończenia operacji, to nie ma mowy o interaktywności.

Innym problemem jest blokowanie i wymieszania logiki biznesowej z UI. Docelowo kod odpowiedzialny z wyświetlanie UI ma być wydzielony i wykonywany przez oddzielny proces. Korzystając z glib, dodam do pętli obsługi komunikatów obsługę zdarzenia zakończenia procesu i odpowiednio je obsłużę. Rozwiąże to problem wymieszania logiki z UI, umożliwi większą troskę o bezpieczeństwo całego rozwiązania, nie będzie blokować, itd. Oczywiście, że w przypadku problemu z zależnościami, nie będziemy od razu wysyłać odpowiedzi - wyślemy ją tylko, gdy proces-dziecko się zakończy (z błędem lub bez).

Innym problemem jest to, że trudno na tym etapie określić inne problemy, bo rozwiązanie jest na wczesnym etapie prac. Jednym, poważnym błędem jest to, że niekiedy gubimy informację o asocjacji procesu Bonsole z daną sesją.