Kolekcja pakietów pkgsrc to szkielet (framework) do budowania aplikacji trzecich na systemach uniksopodobnych. Akio Obata poinformował, że początkowe prace nad wsparciem pkgsrc dla Haiku zostały zakończone.
Obecnie w Haiku możliwe jest zbudowanie podstawowego środowiska (bootstrap). Liczne poprawki zostały bezpośrednio wniesione do pkgsrc, co znacząco ułatwi dalszą pracę. Akio Obata udzielił też wywiadu, tłumacząc swoje intencje przeniesienia pkgsrc na Haiku.
Natomiast Tim Larson zamierza przenieść pkgsrc na Miniksa. MINIX posiada obecnie mocno ograniczony zestaw oprogramowania, gotowego do szybkiego i łatwego użycia. Na chwilę obecną brakuje szczegółowych informacji, na temat efektów jego pracy.
Zespół NetBSD inspirując się menadżerem portów znanym z FreeBSD stworzył pkgsrc, które podobnie jak system NetBSD cechuje się dużą przenośnością. Za cel postawiono sobie zapewnienie wsparcia dla jak największej ilości systemów operacyjnych.
Obecnie pkgsrc obsługuje ponad tuzin OSów, być może niedługo Haiku i MINIX do nich dołączy. Oczywiście liczba aplikacji, która kompiluje się na danych systemach, znacząco się różni.
Kolejne wersje pkgsrc są wydawane co trzy miesiące. Ostatnia wersja pozwala na zbudowanie ponad 9 tysięcy zewnętrznych aplikacji. Jednak w następnym kwartalnym wydaniu liczba ta zmniejszy się ze względu na prace konserwacyjne, które mają teraz miejsce. Masowo są usuwane “recepty” na budowę starych i nie wspieranych programów.
Poszedłem na łatwiznę i próbowałem skopiować zawartość news używając trybu WYSIWYG. Jak się okazało zawartość się rozjechała. Wszelkie uwagi mile widziane.
Źródło informacji to netbsdfr.org. Jednak notatka moim zdaniem nie nadawała się do podlinkowania, temu wrzuciłem odnośnik do swojej strony. Jeśli to przeszkadza redakcji, zmiany są jak najbardziej możliwe.
btw. O ile przeniesienie pkgsrc na Haiku uważam za mało interesujące, to MINIX może sporo na tym zyskać. Wdrożenie gotowego rozwiązania zapewne będzie wymagać mniejszego nakładu sił, niż tworzenie własnego menadżera pakietów.
Szkoda, ze nie front dla portów FreeBSD
DragonFly BSD wspierało przez jakiś czas porty z FreeBSD. Jednak jak się okazało im bardziej system się zmieniał, tym większe problemy były z budowaniem paczek.
Obecnie DragonFly BSD używa pkgsrc i co zauważyłem, to z każdym rokiem jest coraz mniej narzekań na ten "system".
niemniej z roku na rok jest coraz bardziej zacofany względem FreeBSD
Względem czego, ilości paczek?
Pkgsrc posiada odpowiednik yuma/apta w postaci pkgin od dosyć dawna. Co ciekawe pkgin jest obecnie "przystosowywane" do portów FreeBSD.
Jeśli chodzi o architekturę samych portów to OpenBSD posiada znacznie bardziej eleganckie rozwiązanie. Jednak bazuje ono na skryptach Perla.
DragonFly BSD względem jądra FreeBSD
jądro dragonfly wzgledem freebsd
Heh, następnym razem mógłbyś uściślić swoją wypowiedź.
Ekhm, a co złego w tych skryptach perla?
Perl to spora zależność. W OpenBSD to nie problem, bo Perl jest serwowany w systemie bazowym. Zresztą chyba większość systemów/dystrybucji jest rozprowadzana razem z Perlem lub Pythonem.
Osobiście przyzwyczaiłem się w NetBSD, które nie posiada żadnego dynamicznego języka (nie liczę AWK) w podstawowym systemie. Wybór należy do mnie.
Osobiście Perla nie lubię, podobnie jak wiele innych osób. W zależności od programisty kod spełniający tą samą funkcję może się diametralnie różnić. W Perlu jest to szczególnie widoczne i bez dodatkowych komentarzy, często kończy się na "deszyfrowaniu".
Jest to oczywiście moja własna opinia i nie każdy może się z tym zgodzić.
http://www.netbsd.org/docs/software/packages.html…
A tu jest opis wszystkich platform systemowych obsługiwanych przez PKGSRC . Co jak co ale ten system pakietów jest świetny 🙂 Szkoda że nie jest domyślny w opensolarisie
"Świetny" – tego określenia nie użyłbym w odniesieniu do pkgsrc. Osobiście uważam, że jest to bardziej framework niż rozwiązanie odpowiadające końcowemu użytkownikowi.
Pacman nie wymaga praktycznie żadnej wiedzy o swojej budowie i działa rewelacyjne. Natomiast pkgsrc wymaga nakładu sił, a grupa docelowa jest zupełnie inna.
Coś za coś w zamian za utrudnienia dla użytkowników i contrybutorów uzyskano znaczną przenośność
No właśnie. Utrudnienia dla użytkowników. Jest to sprzeczne z filozofią Haiku.
W Haiku konsole powinno się odpalać tylko i wyłącznie w ostateczności. Mam wypasioną myszkę, więc chciał bym nią sobie poklikać. 😉
"Zespół NetBSD inspirując się menadżerem portów znanym z FreeBSD stworzył, które podobnie jak system NetBSD cechuje się dużą przenośnością" – o co chodzi w tym zdaniu?? Jestem bardzo zmeczony i nie potrafie zrozumiec sensu.
Poprawione, zjadło jedno słowo podczas kopiowania.
pkgsrc uzywasz tylko jesli budujesz sam paczki- wtedy sobie ustawiasz opcje kompilacji (z gtk czy z qt, cups czy bez a moze pulseaudio etc). Wiec porownianie pkgsrc do pacmana odpada- raczej pkgin i pacman mozna porownac. Prawdopodobnie uzywajac pkgin tez nie trzeba zbyt wiele znac aby zainstalowac paczke lub wyswietlic jakie paczki sa juz zaisntalowane- albo zaktualizowac paczki.
P.S.
Uzywam tez archa i lubie ten system. Pacman dziala dobrze- w sumie nie mam problemow. Ale brakuje mi troche paczek meta. choc i to sie da rozwiazac: pacmand -Sd na przyklad. Moze kiedys do archa jeszcze wroce 🙂
Kilka paczek meta by się znalazło. Choćby i te od KDE (jest kde-meta-kdebase itd..)
hm… jakie (jesli sa) przewagi ma pkgsrc nad rpmami? rmpy tez sa przenosne (tj. wersja 5), buduje sie je latwo, sa dobrze udokumentowane…
Różnica jest spora. W przypadku RPM sam musisz zadbać o odpowiedni toolchain, żeby zbudować binarne paczki używając srpmów.
Natomiast pkgsrc wykorzystuje narzędzia dostępne w systemie (sh, gcc/icc oraz bibliotekę curses) do zbudowania własnego toolchaina, za pomocą którego tworzone są później paczki.
Druga sprawa jest taka, że wiele programów wykorzystuje specyficzne dla systemu funkcje. W szczególności na niektórych systemach problematyczne może być zapewnienie zgodności z POSIXem. W tym celu pkgsrc wykorzystuje libtoola.
Większość obecnych menadżerów pakietów jest mocno zintegrowana z systemem, pkgsrc jest tego przeciwieństwem.
Haiku nie jest systemem Uniksopodobnym. POSIXowy nie znaczy Uniksopodobny.
Zapewne chodzi ci o pierwsze zdanie w newsie. Haiku to pierwszy system (nie liczę Windowsa tzw. Interix), który nie jest uniksopodoby, na który przenoszone jest pkgsrc.
Haiku nie jest jeszcze oficjalnie wspierane przez pkgsrc, którego funkcjonalność na tym systemie też jest ograniczona. Więc nie widzę problemu w tym zdaniu.
btw. Dzięki za zauważenie tego. Dam znać ludziom od pkgsrc, żeby to usunęli, kiedy wyjdzie stabilna wersja z obsługą Haiku.
Ostatnie zdanie z poprzedniego komentarza dotyczyło opisu na oficjalnej stronie pkgsrc:
Z pomocy SUA (interix) : Utilities compatible with UNIX-based SVR-5 & BSD environments
Temu nie liczyłem Windowsa 😉
W ostateczności można napisać stosowną graficzną nakładkę na pkgsrc , skoro coś takiego jest na porty to będzie i na pkgsrc 😉