Międzydystrybucyjna baza informacji o pakietach
Internet 11th Feb 2008
Jakiś czas temu nawiedziła mnie myśl, która nie daje mi spokoju. Zwłaszcza przypomina mi się kiedy odpalam gtkPacman-a i moim oczom ukazuje się taki widok
Wtedy myślami wracam do czasów Gentoo i bardzo dobrze przemyślanej struktury Portage. Pewnie nie jedna dystrybucja chciałaby mieć tak dobrze skatalogowane oprogramowanie jak Gentoo.
(tutaj pojawia się animacja zapalającej się nad głową żarówki)
A co by było gdyby stworzyć globalną bazę informacji o pakietach? Wystarczy prosta strona www udostępniająca podstawowe API dla wszelkiego rodzaju dystrybucyjnych menadżerów. Taki API mogło by zwracać tekst, HTML lub XML na podstawie wywołanego adresu np.:
http://bazwa.org/package/342432/text
http://bazwa.org/package/342432/html
http://bazwa.org/package/342432/xml
ewentualnie opcja z wersją pakietu (wiadomo, inna wersja inne funkcje inne zależności)
http://bazwa.org/package/342432/0.11.4.2/xml
Wystarczyłoby aby każda dystrybucja stworzyła sobie słownik łączący ichniejszą nazwę pakietu z id pakietu w bazie i voila! Mamy międzydystrybucyjną bazę najświeższych informacji o pakietach, z opisem większym niż jedna linijka, aktualnymi informacjami na temat autora/autorów, strony domowej i (czego najczęściej mi brakuje) zrzutów ekranu. A wszystko ładnie zaszufladkowane i gotowe do przeglądania przez www czy jakiegoś menadżera pakietów.
Oczywiście żeby nie przeciążać serwerów można by codziennie wypuszczać zrzut bazy, który dystrybucje by ssały i hostowały na swoich mirrorach. Hmm.. tylko dlaczego jeszcze nikt tego nie zrobił? Czyżby były jakieś poważne przeszkody o których nie pomyślałem ?
Komentarze z jogger.pl
Rzecz niewykonalna..
1) Różne dystrybucje – różne pakiety – w jednej może być dany program w jedym pakiecie, w innej w 2 a w jeszcze innej w 10.
2) W poszczególnych dystrybucjach dane pakiety mogą różnić się funkcjonalnością – w jedym distro skompilowali program z jedymi flagami, w innej z innymi.
Tak naprawdę wspólnych danych byłoby dość niewiele: ogólne omówienie funkcji, jakiś screenshot.
Przykład:
Kadu – program z obsługą modułów – w jednej dystrybucji wszystko jest w jedym pakiecie, w innych każdy moduł to odrębny pakiet.
Kolejny przykład – programy, które mają kilka interfejsów (powiedzmy w GTK, Qt) w jednej dystrybucji nastawionej na GNOME interfejs Qt zapewne nie będzie skompilowany.
IMO poszczególne dystrybucje zbyt się różnią, aby dało się coś takiego stworzyć..
Uwagi jak wyżej.
Porównaj sobie choćby pakiety Archa i pld…
Choćby KDE ;p
Hmm… czyli to jeden z tych przypadków kiedy różnorodność Linuksa działa mocno na jego niekorzyść :-/
Ale jest też dużo przypadków w których ta różnorodność to prawdziwa potęga.. :)
http://linuxnews.pl/wywiad-z-tworcami-packagekit/ ?
Zobaczymy co im z tego wyjdzie. Ale zrzutów ekranu i tak wiedzę że nie obsługują ;-)
Dlatego nikt nie zrobił, bo widocznie nie ma takiej potrzeby.
Moim zdaniem tak jak jest zrobione w Archu, jest wystarczająco dobre. CRUX ma też fajne porty. A to co jest w gentoo to przerośnięty potwór.
Podział pakietów na core, community i extra to dobre rozwiązanie ? Przecież to rozwiązanie dla developerów a nie użytkowników. Jeżeli na Gentoo chciałem pograć w grę strategiczną to przeglądałem sobie kategorię games-strategy. W Archu nie mam na to szans i o ile pakiet nie jest dobrze opisany to nie znając samych gier nie odnajdę tych strategicznych. Poza tym jak uaktualniał mi się jakiś pakiet, który pierwszy raz na oczy widziałem ale przedrostek miał dev-php to już wiedziałem, że to jakaś biblioteka rozszerzająca możliwości PHP i nie jest super pilna do uaktualnienia. Przykładów mogę podawać mnóstwo.
To chyba świadczy o tym, że pakiety w Archu są poukładane nie tak jak trzeba.. Myślę, że przejście z core/testing/community/extra/unstable na analogiczne flagi rozwiązałoby ten problem. Wtedy pacman mógłby stosować takie kategoryzowanie, jak jest w Gentoo lub podobne. Schody będą dopiero wtedy, gdy ktoś będzie chciał zorganizować własne repozytorium…
Własne repozytoria mogły by działać warstwowo, na zasadzie Gentoo Overlays Każde repozytorium trzyma się architektury kategorii a pacman przeszukiwałby repozytorium główne oraz wszystkie dodane do niego warstwy (inne repozytoria) i wybierał najnowszą wersję pakietu. Jeżeli znalazł go w jakieś inne warstwie niż główna pokazywałby jej nazwę.
Analogiczne do portage:
Tak, znam ten mechanim. Schody zaczynają się wtedy, gdy mamy różne wersje jednego pakietu – monolit/modularna albo stabilna/cvs|git|svn. Niby można to też rozstrzygnąć przez flagi dla buildów, ale jest to chyba komplikowanie życia.
Jeśli już jesteśmy w sferze rozważań, co warto uwzględnić – to brakuje i to bardzo jakiegoś ogólnego systemu zarządzania patchami, nawet w obrębie jednej dystrybucji. Arch na ile przeglądałem PKGBUILDy ma zwykle niepatchowane pakiety, Gentoo patchuje prawie wszystko. :) A Debian dla odmiany, choć w repozytorium ma pakiety stabilne w wersji muzealnej, to funkcjonalność mają podobną do najnowszych. O patchowaniu w Suśle, RH i w Ubuntu nawet wspominać nie będę. Patrys poświęcił temu prawie całą notkę na swoim blogu
Natomiast bezwzględnie zaadoptowałbym do Archa znany z Gentoo sposób zarządzania plikami konfiguracyjnymi do uaktualnienia. Obecne rozwiązanie jakoś mi nie odpowiada.
Heh, to jest temat na osobny brain-storm a nie na spamowanie Husiowi bloga :)
A naszego piszczenia i tak nikt nie usłyszy… ;-)
Argh, przechrzciłem Tomka Karbownickiego na Husia przypadkiem. Sorry :)
Dość mojego spamu tutaj na dziś