5 stycznia 2008 Jeff „JBJ” Johnson poinformował o ukończeniu prac nad swoją wersją 5.0 popularnego systemu pakietów RPM. Tym samym wystartowały prace nad 5.1.
Jeff to dawny opiekun RPM w Red Hat i obecny lider wolnego projektu rpm5.org, założonej 29 maja 2007 roku pierwszej rozwojowej gałęzi RPM z piątką w nazwie. Końcowy efekt jest wspólnym wysiłkiem Jeffa, społeczności OpenPKG i grupy współpracowników.
Podstawową cechą nowego RPM 5 ma być zerwanie z „linuksocentryzmem” i silnymi związkami z poszczególnymi dystrybucjami; twórcy obiecują szerokie wsparcie dla wszystkich systemów uniksopodobnych – od BSD, przez Linuksa i Solaris po Mac OS X.
Nowa wersja to także oczyszczenie i usunięcie wielu historycznych porcji kodu oraz dodane wsparcie dla formatu kompresji LZMA – oraz wstępne dla XAR.
Niestety, wsparcie gałęzi rpm5.org deklarują nieliczne i nienajwiększe projekty, takie jak polskie PLD. Użytkownicy najpopularniejszych RPM-owych dystrybucji, takich jak Red Hat/Fedora, SuSE i Madriva, muszą uzbroić się w cierpliwość. Projekty te rozwijają własną piątą wersję RPM rozwijaną przez społeczność rpm.org, która to wciąż znajduje się w powijakach.
Hmm, akurat o cyrku wokół rozwoju RPM i jego forkach wiadomo od pół roku, a całą sprawę można było przewidzieć znacznie wcześniej.
Projekt rpm5.org miał być odpowiedzią na stagnację i powolne "gnicie" kodu RPM, do którego nikt się nie poczuwał (no, Red Hat chciał mieć kontrolę, ale nie chciał tego sam utrzymywać; a inni nie bardzo spieszyli się z przyjściem z odsieczą). A kiedy już rpm5.org wystartowało, okazało się, że wizja Red Hata jest inna i zrobili własny fork.
Do tego wszystkiego doszły jakieś walki o serwery, domeny i wiele skomplikowanych rzeczy. 🙂 Koniec końców, teraz możemy obserwować co dalej (lub ohoczo włączyć się do programowania czy agitowania za jakąś opcją ;] ).
Nie wiem czy Jeff był pracownikiem, natomiast co do rozwinięcia skrótu – podaj oryginalne źródło (np. jakieś źródła z tamtych czasów). ZTCW to nigdy nie był RED HAT Package Manager. http://groups.google.com/group/pl.comp.os.linux/b…
Tak, wbrew temu co napisano w Maximum RPM oraz w Wikipediach.
OFFTOPIC, bo przecież to, jakie było oryginalne rozwinięcie skrótu RPM, nie ma żadnego znaczenia. A co do właścicielstwa nazwy – pamiętasz sprawę Ethereal/Wireshark?
> Nie wiem czy Jeff był pracownikiem
Był do 2005, choć to akurat też nie ma znaczenia, bo zaczął pracować nad RPM, gdy ten już istniał. Nie ukrywa tego nawet na rpm5.org:
"RPM was originally written in 1997 by Erik Troan and Marc Ewing for use in the Red Hat Linux distribution."
> natomiast co do rozwinięcia skrótu – podaj oryginalne
> źródło (np. jakieś źródła z tamtych czasów).
Ot, choćby howto z 1997:
http://ftp.icm.edu.pl/pub/unix/database/rpm/docs/…
"RPM is the Red Hat Package Manager."
Źródła starych wersji masz tam, obejrzyj sobie many z wersji 1.x i plik README w wersjach 2.x, 3.x itd. aż do 4.3.x
http://ftp.icm.edu.pl/pub/unix/database/rpm/dist/
> ZTCW to nigdy nie był RED HAT Package Manager.
No to się mylisz 🙂
PHP też się nie chwali, że oryginalnie było to "Personal Home Pages" – później dorobili sobie "PHP Hypercośtam"
Nie chcę się spierać, ale "zabawę" z PHP zacząłem jeszcze w '98 (kawał czasu, co?) od wersji "dwa-coś-tam", i naprawdę pamiętam z tamtego okresu rozwinięcie "Pretty Home Page". Może funkcjonowało ono równolegle z "Personal", a może jakoś "nieoficjalnie"(?)… nie wiem, nie ma to teraz większego znaczenia.
Nie zawsze. Już teraz Linux jest krytykowany za mnogość rodzajów pakietów, a jeszcze jeden (oczywiście niekompatybilny z resztą jak mniemam) tylko pogorszy sprawę…
Na pewno PLD będzie potężniejsze. Z drugiej strony, wdrożone nowiutkie ficzery RPM'a w PLD to jest jedna z nielicznych (lecz intensywnie) podpatrywanych przez inne distra funkcjonlonści. Ile to już razy bywało że różne Fedory i inne zgapiały całe fragmenty SPEC'ów z PLD bez głębszego zrozumienia, bo ładnie wyglądały. Ot taki towar eksportowy. Więc z czasem inne distra też staną się kompatybilne…
Żeby dobrać się pakietów Debiana/Ubuntu wystarczy użyć ar i tar – są w każdej dystrybucji. Inne dystrybucje jak Slackware czy Arch stosują najzwyklejsze archiwa tar. Żeby dobrać się podstawowymi narzędziami do rpm trzeba magicznymi sposobami obliczyć wiekość nagłówka, odciąć go i dopiero wtedy można użyć gzip czy bzip2 oraz cpio. Wprawdzie Jeff Johnson napisał kiedyś skrypt, który potrafił wyciąć z początku pliku odpowiednią ilość bajtów, jednak ze względu różnorodność wersji rpmów niezawsze prawidłowo on działa (chyba miałem problemy z pakietami PLD – nie pamiętam). W moim odczuciu komplikacja tego formatu (standardy są dobre o ile są _nasze_ standardy) kłóci się z filozofią która przyświeca otwartości – przecież nawet ODF to zwykły zip – stąd unikam dystrybucji i pakietów opartych na rpm od 1999 roku.
RPM-y są dostarczane zarówno w wersji binarnej, jak i źródłowej. Dlatego zasadność idei rozbierania gotowego RPM-a można poddać w niemałą wątpliwość. Jeśli istnieje potrzeba modyfikacji binarki, to można to zrobić po instalacji plików w systemie. A jeśli ktoś chce dostarczać zmodyfikowany pakiet, to na podstawie istniejącego źródłowego buduje swój i udostępnia.
Nie doszukiwałbym się tutaj zamkniętości (czy raczej nieotwartości). To po prostu odmienna filozofia.
ale czasem możemy chcieć dorzucić pojedynczy plik z nowszej/starszej wersji pakietu POZA systemem zarządzania pakietami; ostatnio dorzuciłem jakąś bibliotekę do sarga, żeby najnowszy blender ruszył
ech, niestety ebuildy nie naleza do najprostszych wynalazkow, a dodatkowo trzeb czytac makefile bo moga cos instalowac poza katalogiem. O niebo latwiej pisze sie pliki do pacmana(arch linux) i nie trzeba kombinowac z makefile bo instalacja odpalana jest w chroot.
Niestety, wsparcie gałęzi rpm5.org deklarują nieliczne i nienajwiększe projekty, takie jak polskie PLD. Użytkownicy najpopularniejszych RPM-owych dystrybucji, takich jak Red Hat/Fedora, SuSE i Madriva, muszą uzbroić się w cierpliwość. Projekty te rozwijają własną piątą wersję RPM rozwijaną przez społeczność rpm.org
I to caly problem z Linuxem, zamiast rozwinac jeden standart (jak pkgsrc.org) i miec kompatybilnosc pomiedzy dystrybucjami na RPM, to lepiej stworzyc 15 niezaleznych "standartow" :/
FreeBSD to nie NetBSD, to nie dwie dystrubucje Linuxa tylko dwa ROZNE systemy operacyjne, wiec ciezko tak po prostu sobie wziasc FreeBSD Ports i wrzucic do NetBSD, pozatym pkgsrc.org obsluguje teraz 14 systemow operacyjnych [ http://www.netbsd.org/docs/software/packages.html… ], a RPM dalej tylko jeden, i to tez srednio bo trza miec inna wersje na RedHat, inna na Suse itd, i raczej sie to nie zmieni.
A ja myślę, że się zmieni, bo zmianę tę wymusi rynek, użytkownicy etc. Widać już to ciśnienie chociażby w tym, że powstają próby tworzenia systemów uniwersalnych, widać że problem jest już zauważony i teraz pozostaje czekać aż jedno z istniejących lub nadchodzących rozwiązań zostanie zastosowane. Wydaję mi się, że największy nacisk na rozwiązanie tego problemu przyniesie coraz większa popularność linux'a na desktopach.
JA nie widze tej tendencji ktora opisujesz i nie wierze ze to sie predko zmieni. Nie wierze tez aby mozna bylo szybko i bezbolesnie przejsc w danej dystrybucji z jednego systemu pakietow na drugi, pozatym żadna z dystrybucji raczej nie porzuci swojej chluby. Jesli te systemy maja sie przyjac to musza powstac nowe dystrybujcje od poczatku oparte na tych systemach pakietów.
Nie jest chyba konieczne tworzenie od nowa takich dystrybucji. Najprostrzym pomysłem jest to, żeby każda dysytrybucja posiadała wrappery/translatory różnych pakietów, które instalowało by się jak tradycyjną paczkę. Debian już wspiera paczki w formacie RPM (nie wiem jak dobrze) – instalowałem ten format paczek na tym systemie. Nie przypominam sobie abym na openSUSE miał taką możliwość (może wtedy nie szukałem za dobrze).
Równiez myśle, ze nie jest konieczne tworzenie nowych dystrybucji. Po prostu uniwersalny system pakietów, będzie działał przez jakis czas obok pakietów dystrybucyjnych, by z czasem wyprzeć je zupełnie.
Narazie na najlepszej drodze ku temu jest
http://www.cnr.com/index.seam
Póki co obsługuję Freespire, Linspire i Ubuntu (w Ubuntu działa bardzo fajnie).
Jednak jak można przeczytać cnr będzie w przyszłości także obsługiwał Fedore i Opensuse, wiec kto wie…może to będzie kolejny krok do ujednolicenia pakietów.
A ja widzę to dokładnie, chociażby LSB, chyba w następnej wersji, ma już zawierać, pierwsze wytyczne w tej sprawie, nie wiem czy pamięć mnie nie myli, ale chyba ma być nawet jakieś początkowe api czy sdk (oczywiście nie w LSB) i nie chodzi tu o stworzenie nowego systemu pakietów, tylko wytyczenie pewnego szkieletu, sposobu rejestracji zainstalowanych programów, bibliotek etc. w systemie (opis bazy danych itp) jak i mechanizmów z tym związanych. Jak mniemam poszczególne systemy pakietowe dostosują się do tego wprowadzając odpowiednie modyfikacje, co pewnie dopiero wyzwoli impuls do powstawania wrappery itp. Co do rynku, to sądzę, że mnogość oprogramowania, szczególnie komercyjnego (np. gry i inne) wymusi potrzebę takiej standaryzacji, a do tego potrzebny jest silniejszy udział linux'a na stacjach zwykłych użytkowników, czyli możliwość masowego odbioru produktu.
pozatym pkgsrc.org obsluguje teraz 14 systemow operacyjnych [ http://www.netbsd.org/docs/software/packages.html… ], a RPM dalej tylko jeden,
Bzdury waść klepiesz. rpm jest używany(!) chociażby na aixie. Jak również znam ludzi którzy korzystają/korzystali z niego choćby na tru64. Więc twierdzić że rpm obsługuje tylko linuksa to tak trochę na bakier z prawdą 😉
Bzdury waść klepiesz. rpm jest używany(!) chociażby na aixie. Jak również znam ludzi którzy korzystają/korzystali z niego choćby na tru64. Więc twierdzić że rpm obsługuje tylko linuksa to tak trochę na bakier z prawdą
No to juz troche lepiej, tylko pytanie, czy jest to RPM z tego samego drzewa, czy dla kazdego systemu mamy inna wersje, osobna wersja na AIX + osobna wersja na Tru64 + osobna wersja na RedHat + …
Czy jakos sensownie jak z OpenPKG [ http://www.openpkg.org ] na przyklad.
To troche tak jak z iloscia obslugiwanych architektur pomiedzy NetBSD a Linuxem, Linux obsluguje wiecej architektur niz NetBSD, ale co z tego skoro musisz miec dla wielu z tych egzotycznych architektur osobna wyspecjalizowana dystrybucje, a przy NetBSD wszystkie sa obslugiwane z jednego drzewa i wszedzie mozna miec NetBSD + pkgsrc.org
@vermaden: Wlasciwie to pod kazda chyba z tych architektur masz Debiana. Mozesz sobie alienem paczki przekonwertowac. ;-P
Inna sprawa to jakosc tego dzialania. Debian/sparc64 mial (moze i nadal ma) na przyklad blad w bootloaderze, uniemozliwiajacy dzialanie systemu na U5 (i pewnie paru innych). Ostatnio jak patrzylem, blad nadal tam byl, znany od co najmniej pol roku.
Dodaj komentarz