Wydano nową wersję pkgsrc – multiplatformowego systemu pakietów
- Dodano: 18 stycznia 2009
- Wprowadził: Javaanse-Jongens
- Komentarze: 55
12 stycznia poinformowano na liście dyskusyjnej o nowej stabilnej wersji systemu pakietów pkgsrc. Lista wszystkich dostępnych pakietów obejmuje 8121 pozycji.
Wsparcie dla pkgsrc i możliwość kompilacji programów posiadają obecnie: AIX, BSD/OS, Darwin, MacOSX, Dragonfly BSD, FreeBSD, OpenBSD, NetBSD, HP/UX, Irix, Interix, Linux, QNX i SunOS (Solaris i prawdopodobnie OpenSolaris).
Najważniejsze zmiany to:
- dostępny Pulseaudio,
- poprawiona obsługa HAL,
- poprawione błędy z poprzedniej wersji pkgsrc.
Dodano nowe wersje programów: OpenOffice 3, Firefox 3.0.5, KDE 3.5.10.
Obecnie pkgsrc wspiera 14 rożnych platform, kompilację skrośną, łatwe zarządzanie systemem pakietów.
Więcej informacji można zaczerpnąć ze źródeł:
Ogłoszenie stabilnej wersji
Strona główna pkgsrc
Strona główna NetBSD.
Więcej informacji: http://mail-index.netbsd.org/pkgsrc-user...09034.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
55 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Ten koszmarek 'kompilacja skrośna' to po jakiemu? Bo mam nadzieję, że nie po polsku. Pytając wprost: czy to standard tłumaczenia zwrotu 'cross compilation', czy może jest jeszcze szansa na to, że przyjmie się coś normalnego?
Nie jestem purysta wiec chętnie przeczytam 'polskie' tłumaczenie
No właśnie chodzi o to, że sam nie wiem jak to się tłumaczy. Ja bym pewnie zostawił kroskompilację, ale może jest lepsze tłumaczenie. Skrośny sugeruje, że jest to przymiotnik odrzeczownikowy, tylko tego rzeczownika w języku polskim nie ma. Od biedy może być kompilacja krzyżowa, to jest przynajmniej po polsku.
W paru książkach widziałem właśnie takie sformułowanie…
Również widywałem to sformułowanie, ale wyłącznie w internecie. Miałem po prostu nadzieję, że nie jest to jeszcze sformalizowane. Wygląda na to, że się już przyjeło.
Takie sformułowanie funkcjonuje od dawna w literaturze fachowej ( wiecie, informatyka istniała długo przed powstaniem internetu… )
… a może "kompilacja krzyżowa", jak "zapłodnienie krzyżowe" w botanice, znaczeniowo podobne, choć może się mylę…
To ja mam propozycję – tłumaczmy cross compilation jako zapłodnienie krzyżowe po prostu. Nie, żeby to miało jakiś sens! Po prostu rozwiąże Wasz problem. Co wy na to?
Bo Vasc już stosowny link dodał poniżej. Jednak założę się, że deliberacji na temat "kompilacji skrośnej" zobaczę jeszcze tysiąc (_kolejny_ tysiąc).
No chyba, że się zgodzicie i zaczniemy pisać zapłodnienie krzyżowe.
pawel k: ode mnie masz + za dowcip
Po prostu zaliczyłem rotfla jak to przeczytałem ^_^
Coś w temacie tłumaczenia słowa "cross" w polskim języku. pytanie w poradni językowej PWN
Czyli wygląda na to, że się jednak przyjmie. Czy tylko dla mnie to tak rażąco brzmi?
Mnie wcale ta nazwa nie razi.
Wręcz przeciwnie bo "kroskompilacji", która nic nie mówi i z niczym się nie kojarzy.
A co do pkgsrc – właśnie testuje to na NetBSD i jestem zauroczony prostotą i tym że to po prostu działa. Jedyne minusy jakie jak dotąd zauważam w tym taki iż wyszukiwanie paczek jest trochę utrudnione i że rozpakowane archiwum z danymi pakietów zajmuje prawie 200 mb na dysku.
Mały koszmarek wyszedł a nie komentarz, a nie jestem w stanie go edytować.. Sensowniejsza wersja:
Mnie wcale ta nazwa nie razi. Wręcz przeciwnie do “kroskompilacji”, która nic nie mówi i z niczym się nie kojarzy.
A co do pkgsrc – właśnie testuje to na NetBSD i jestem zauroczony prostotą i tym że po prostu działa. Jedyne minusy jakie jak dotąd zauważyłem: wyszukiwanie paczek jest trochę utrudnione i rozpakowane archiwum z danymi pakietów zajmuje prawie 200 mb na dysku..
Hej,
kompilacja skrośna nie jest jakimś koszmarkiem
To dosłowne tłumaczenie cross compilation. Kroskompilacja to jest dopiero koszmarek 
Ten zwrot "kompilacja skrośna" jest używane w informatyce. Więc jeśli można użyć polskiego zwrotu to czemu nie.
Wikipedia
Gentoo
Politechnika Łódzka
Więc ten zwrot istnieje nawet w języku akademickim
Tak pkgsrc jak i NetBSD jest całkiem przejrzyste. Fakt zajmuje > 200MB ale myślę, że to nie problem w dzisiejszych czasach.
Wyszukiwanie paczek jest uproszczone przez program pkgfind w pkgsrc/pkgtools/pkgfind.
To chyba na tyle,
Dzięki,
P.
wyszukiwanie paczek
cd /usr/pkgsrc/*/*_nawa_paczki*
lub pkgsrc.se
dwa najprostsze sposoby.
Dla mnie również to brzmi dziwnie.
Do wszystkich "antypolonistów": bylejakość językowa jest zazwyczaj efektem bylejakości w ogóle. Sposób wypowiadania się danej osoby bardzo wiele o niej mówi. Ktoś, kto nie dba o poprawne wyrażanie się w języku (podobno) ojczystym zazwyczaj jest równie niedbały w innych dziedzinach, np. w pracy.
Pokażcie mi pracodawcę, który przyjmie do pracy bełkoczącego niezrozumiale aplikanta.
Mozesz to "zazwyczaj" usciclic??
>>jolsky nie jestem przeciwko stosowaniu poprawnej polszczyzny, ale kiedy czyta się kolejny artykuł i widzi się znowu atak "grammar nazi" to się odechciewa wszystkiego.
Jednym z efektów ubocznych "waszej" walki o poprawną ortografię, gramatykę etecera jest notoryczne zabijanie ciekawej dyskusji.
Akcje typu "Bykom Stop" wydawały się początkowo ciekawe, w rzeczywistości przerodziły się w jeszcze jeden sposób trollowania. Tutaj bez urazy.
"kompilacja skrośna" to jest właśnie poprawne tłumaczenie tego terminu
dla mnie okreslenie skrosna to nie wiem co za nieudany neologizm, bo corss compilation to jest kompilacja krzyzowa a nie jakas skrosna – co to wogole znaczy- skrosna?
jak zwykle
jak zaaawsze
rozmowa na temat!
naprawdę zamknęli forum wielbicieli języka polskiego?
Czuje sie chory jak widze te arcy rzeczowe dyskusje polonistow, zalozcie sobie jakies forum i tam uskuteczniajcie te swoje jakze potrzebne nam wszystkim dyskusje.
wienc muwisz rze nie ophodiz cie jakosic jenzyka jakim sie poslugójemy?!!!
No tak niema to jak wpadac ze skrajnosci w skrajnosc.
jr, zastanawiam się, czy to miał być dowcip, czy zwykłe czepialstwo… Chyba jednak czepialstwo, bo przy dowcipach na ogół dorzuca się jakąś emotę podkreślającą charakter wypowiedzi.
Wszyscy popełniają błędy. Przesadne czepianie się to przegięcie jakich mało.
Inna sprawa, że jest koleś, któremu zacząłęm poprawiać wszystkie słowa z błędami na "orty"… tylko że u niego po moich korektach zostawały same przecinki. Przez pierwszy tydzień
Nie czepialstwo tylko argumentacja przez sprowadzenie do absurdu. Wszyscy popełniają błędy, ważne jednak jak się do tych błędów podchodzi. Z resztą w pierwszym komentarzu nie chodziło mi o błędy, a o tłumaczenie terminu fachowego, które dopiero powstaje. Poloniści za nas tego nie załatwią (patrz link do poradni językowej w komentarzu vasc). To my zaakceptujemy bądź nie termin kompilacja skrośna.
> wienc muwisz rze nie ophodiz cie jakosic jenzyka jakim sie poslugójemy?!!!
cze skont klikash?
Hmmmm….. projekt ciekawy ale i tak paczkuje się dla konkretnego distro… Ktoś może coś słyszał o standaryzacji paczek? Kiedyś było o tym głośniej a teraz coś cicho się zrobiło.
Problem ze standaryzacją polega na tym, iż prawie każda dystrybucja różni się od innej, często nawet w BARDZO znaczący sposób, na przykład rozkładem plików konfiguracyjnych lub nawet własnym, zmodyfikowanym jądrem systemu.
Powstać musiałaby więc kolejna dystrybucja, zastępująca wszystkie obecne, bo po co Ubuntu, Debian, Gentoo, FreeBSD i NetBSD, kiedy systemy właściwie dzieliłyby się tylko na dwa: Linux i BSD.
A właściwie… czy różnorodność nie jest piękna ?
Zgadzam się
bardzo lubię tą różnorodność, ale akurat paczki powinny być ustandaryzowane ponieważ im więcej distro tym więcej rodzajów paczek, a co za tym idzie programiści też muszą się bawić w paczkowanie.
Tylko jak zmusić programistów zeby ustandaryzowali paczki? Albo stworzyli jeden rodzaj do wszystkich dystrybucji.
Autopackage, zero install i parę innych. Ten drugi jest o tyle ciekawy, że działa na GNU/Linuksie, BSD i Mac OS
Jest to 'ustandaryzowane' w Linux Standard Base (http://en.wikipedia.org/wiki/Linux_Standard_Base). Oficjalnym standardem dla pakietów jest RPM..
Osobiście używam Arch Linuksa z pięknymi prostymi paczkami
A tak właściwie, to co każdy z nas rozumie pod pojęciem "standaryzowania paczek"? Jedno ogromne repo i jeden rodzaj paczek + jeden program do zarządzania paczkami?
A co z kompilacją? Mechanizm podobny do tego z Gentoo, czy także "jeden słuszny", np. i386? A może wybór przy samym pobieraniu paczki czy chcemy i386, czy i686, lub może coś zupełnie innego?
Kompilacja jest opcją. Normalnie masz paczki z wersji stabilnej pkgsrc-2008Q4 na prawie wszystkie platoformy (jest ich 57) w kilka dni (czasem tygodni w przypadku mniej popularnych platform) na ftp- więc możesz te paczki instalować przez pkg_add (wcześniej zmienasz tylko zmienną PKG_PATH). Jeśli chcesz mieć paczki pod konkretny porcesor to wtedy musisz sobie ustawić opcje np CFLAGS w pliku /etc/mk.conf i skompilować paczki. NetBSD nie ma jednej słusznej drogi.
@sl3dziu: Tyle, ze LSB jest tylko Linuksowe, a pkgsrc – przenosne.
Pkgsrc jest standardem- skoro można skompilować podnad 8K paczek z jednego stabilnego źródła na tylu platformach (procesor), systemach to to jest dla mnie standard. Tylko nie wiem dlaczego niewiele projektów to wykorzystuje (a szkoda).
Przypominam też o projekcie pkgsrc-wip
Powiedziałeś praktycznie wszystko o czym myślałem. Bardzo fajnie, że pojawił się ten news.
Inna ważna moim zdaniem sprawa to brak zależności między wersją pkgsrc, a wersją systemu. Nic nie stoi na przeszkodzie, żeby korzystać z NetBSD 3.1 i pkgsrc 2008Q4. System nie musi być aktualizowany, żeby można było skorzystać z nowszych "paczek".
Nie pkgsrc (obojętnie jak wersja) działa niezależnie od wersji systemu (jakiegokolwiek). Co więcej, jeśli uzywasz NetBSD możesz zbudować sobie "sandbox" lub "piaskownicę" i na jednej wersji systemu kompilować paczki na inne wersje systemu (np pod NetBSD-3.0 budujesz paczki na NetBSD-4.0). Itd itp …
Nie lubię sam siebie cytować: "Inna ważna moim zdaniem sprawa to brak zależności między wersją pkgsrc, a wersją systemu."
Więc nie wiem o co chodzi koledze. Powiedziałeś dokładnie to samo co ja, tylko innymi słowami.
Chyba już jestem zmęczony
To jest jakas paranoja. Zeby ponad strona komentarzy dotyczyla tlumaczenia jednego slowa, a nie samego news'a. Idzcie sobie podyskutowac na jakies forum poprawnej polszczyzny i to co wydumacie zamiesccie jako artykul tygodnia: "Po wielu latach starań ustalono w jaki sposob tlumaczyc slowo X z tajskiego na nasz". Podejrzewam ze zainteresowanie tym bedzie tak duze ze moze zostanie newsem roku, a autorom wybuduja pomnik (tak jak tym od dyskusji java/dzawa). A tym czasem odpier… sie od kazdej literowki/bledu rozwodzac sie nad tym w komentarzach. Od tego jest formularz…
Co do samego pkg-src, to musze wreszcie sie do niego przymierzyc. Ktos ma moze doswiadczenie jak to sie sprawuje na Solarisie ?
Jeśli chodzi o Solarisa (ja będe testował na swoim Ultra 60 w tym tygodniu) zrobię według tego opisu:
Wiki NetbSD> i także według tego opisu NetBSD Doc>. Nie wiem tylko jak to będzię się spraowało z oryginalnym serwerem Xów (bo nie chcę mieć Xorg z pkgsrc bo nie wspiera XVR-1200).
Z pkgsrc korzystałem na Slackwarze i nie narzekałem. Na internecie można znaleźć wywiad z użytkownikami tego menadżera pakietów (bardziej to przypomina porty, ale tą nazwą określane są platformy na których działa NetBSD), którego używają na systemach innych niż NetBSD.
hm… czy to daje porownywalne mozliwosci konfiguracji jak rpm?
jak tworzy sie takie paczki?
Wszystko o tworzeniu paczek i pkgsrc jest tutaj:
NetBSD Doc>.
pkgsrc bardziej przypomina porty znane z FreeBSD czy ebuildy z Gentoo (oczywiście są różnice). Co prawda dostępne są binarki, ale częściej instaluje się ze źródełek. Jak to wygląda?
Najpierw sciągamy drzewko pkgsrc i rozpakowujemy (pkgtools etecera też się przyda). Przykładowo chcemy zainstalować Basha. Wchodzimy w odpowiedni katalog:
>> cd /usr/local/pkgsrc/shells/bash
I wydajemy komendy:
>> make && make install
Jeżeli chcemy zobaczyć co mamy zainstalowanego wpisujemy:
>> pkg_info
Aby odinstalować aplikację (pewnie ktoś przyczepi się za tą nazwę) to znowu wchodzimy do odpowiedniego katalogu i wpisujemy:
>> make deinstall
Prościej się chyba nie da, jeśli chodzi o pakiety.
Tworzy się przez make install lub make package (wtedy także tworzona jest paczka).
Odinstalować należy przez pkg_delete.
> ale częściej instaluje się ze źródełek.
Może jest o i częste, ale warto polecić budowanie pakietów – szczególnie dla systemów produkcyjnych, gdzie nie chcemy ryzykować wyłączenia usługi na godzinę/dwie potrzebne do przebudowania jakiejś biblioteki i jej wszystkich, możliwych zależności (jeśli zabierzemy się za przebudowę jakiejś kluczowej biblioteki, np. BerkeleyDB, to przy "make update" pkgsrc odinstaluje i przebuduje zależne komponenty). To nie zawsze może być dobrym pomysłem. Ale zawsze możemy zrobić kopię /usr/pkg i odtworzyć wszystko jednym poleceniem "tar".
Osobiście wykorzystuję pkgsrc z CentOS/RHEL, Debianem3/4/5 i NetBSD. Dla każdego środowiska mam osobny chroot, w którym mogę sobie bezpiecznie budować dowolne, potrzebne paczki. Pkgsrc pozwala na instalację przez sieć bez dodatkowych wrapperów (wystarczy podać, jako miejsce położenia pakietów, lokalizację zaczynającą się od http:// lub ftp://) więc uaktualnienia pojedynczych paczek są bardzo łatwe i szybkie.
Dla przypadków, w których na kilku serwerach mam identyczne środowiska, stosuję następującą metodę: wydzielone miejsce, w którym wykonuję i testuję instalację a na serwerach produkcyjnych skrypt, który za pomocą rsync synchronizuje całe drzewko /usr/pkg – działa to doskonale.
Jeśli chodzi o elastyczność, to rpm czy dpkg zostają naprawdę daleko w tyle. W pliku konfiguracyjnym pkgsrc można podać interesujące nas opcje (np. dla dovecota wsparcie dla ipv6/ssl/postgresa) i budować dokładnie takie paczki, jakie nas interesują. Podobnie możemy pilnować uidów/gidów przeznaczonych dla poszczególnych użytkowników wykorzystywanych przez aplikacje (użytkownicy Debiana znają ten ból).
Gdy potrzebujemy określonego zestawu oprogramowania, to przebudowa jego nowszych wersji może polegać na wydaniu jednego polecenia "make package" – wystarczy przygotować sobie, śmiesznie prosty, plik będący definicją "meta-pakietu". Czyli pakietu z pustą zawartością, zawierającego zależności od X wybranych aplikacji. System sam zbuduje, zainstaluje i spaczkuje wszystkie potrzebne programy. Przydaje się, gdy chcemy wykonać jakieś poważniejsze uaktualnienie i naprawdę nie mamy ochoty wchodzić do trzydziestu czy czterdziestu katalogów, by napisać w nich oddzielne "make".
Ogólnie, zalet pkgsrc ma wiele (co mogę napisać jako osoba tworząca kiedyś rpmy i regularnie przebudowywująca deby). Wymaga wyrobienia sobie pewnych nawyków i czasem wiąże się z pewnym kłopotliwymi sytuacjami, ale gdy opanuje się to narzędzie, to naprawdę można wiele (i bez wysiłku) dokonać.
Dzięki za obszerny opis. Doświadczenia w środowisku produkcyjnym znacząco różnią się od systemu desktop do prywatnego użytku. Jak znajdę czas to dogłębniej potestuję pkgsrc.
czy ten system pakietow jakos stara sie rozwiazac problmy wynikajace z braq api unixa i biblotek systemowych?
Nie za bardzdo rozumiem ? Możesz rozwinąć? Dzięki.
Myślę, że chodzi o zależności, chociaż pewien nie jestem.
ja sie obawiam ze 'kolega' sam nie wie o co sie pyta :~
pewnie kolega ma na myśli to czy ciągnie zależności, gdy takie będą wymagane. Przynajmniej ja to tak zrozumiałem
Tak, jeśli program który kompilujesz wymaga innego programu do działania to pkgsrc samo zadba o zależności. Więc sprawa prosta.