Dlaczego programiści systemu Linux nie mogą stworzyć uniwersalnego formatu opakowania?

Wybór formatu pakietu binarnego dostawcy wydaje się być określony przez formę prawa Murphy'ego: wszystkie dystrybucje, których nie używasz, mają pakiety. (Corralary: nie istnieje dystrybucja, która spełniałaby zależności dystrybucji stosu oprogramowania).

Czy to kwestia polityki, czy coś głębszego, że nie widzieliśmy pojawienia się formatu pakietu „buduj raz, uruchamiaj gdziekolwiek”?

Wydaje się właściwe zacytowanie Joela Spolsky'ego na ten temat:

(Nawiasem mówiąc, dla tych z was, którzy śledzą tajemny, ale politycznie naładowany świat formatów kanałów syndykacji blogów, można zobaczyć, że dzieje się tam to samo. RSS zostało podzielone na kilka różnych wersji, niedokładne specyfikacje i wiele walk politycznych, a próba oczyszczenia wszystkiego poprzez utworzenie jeszcze jednego formatu o nazwie Atom spowodowała powstanie kilku różnych wersji RSS plus jednej wersji Atom, niedokładnych specyfikacji i wielu walk politycznych. Gdy spróbujesz zjednoczyć dwie przeciwne siły, tworząc trzecią alternatywę, po prostu masz trzy przeciwne siły. Nic nie zjednoczyłeś i tak naprawdę niczego nie naprawiłeś.)

(podkreślenie dodane)

Masz (przynajmniej) dwa systemy pakowania dla systemu Linux. To właściwie dobra rzecz. Pojedynczy system po prostu utworzy trzeci system.

Jest tego wiele przyczyn, a trochę historii ma na celu ujęcie perspektywy.

Pamiętaj, że kiedy mówimy o „Linuksie”, ogólnie mamy na myśli jedną z wielu różnych dystrybucji Linuksa . „Linux” jest w rzeczywistości tylko jądrem systemu operacyjnego.

Pierwotnym celem Linuksa było stworzenie systemu uniksowego, który działałby na komputerach PC (początkowo 386). Pierwszym krokiem było stworzenie samego jądra. Podczas gdy Linus Torvalds pracował nad jądrem, Richard Stallman pracował nad własnym systemem Free Unix, w ramach projektu GNU (Not Unix) GNU . Krótko mówiąc, oba były w pewnym stopniu zbieżne, ponieważ GNU miał powiązane narzędzia (kompilator C / biblioteki / narzędzia do budowania, powłokę, edytory tekstu itp.), Ale nie miał rdzenia, na którym można go uruchomić, a Linux miał rdzeń, ale nie miał narzędzi do biegnij na nim, aby był użyteczny dla mas.

Ta konwergencja stała się nieco oficjalnie znana jako GNU / Linux. Przekonasz się, że wiele dystrybucji wciąż nazywa się dystrybucjami GNU / Linux.

Ze względu na darmową i otwartą naturę GNU / Linuksa każdy mógł go podnieść i stworzyć pakiet według własnego gustu. Rezultat był taki, że do stworzenia tych systemów wykorzystano wiele różnych strumieni różnych metod konfiguracji, co miało efekt uboczny polegający na utworzeniu prawie tyle różnych systemów zarządzania pakietami, które pasowałyby do każdego z nich.

Każdy inny kompletny system miał swoich silnych naśladowców, którzy utknęli z nimi przez lata, w wyniku czego mamy dzisiaj: garść szeroko używanych, głęboko zakorzenionych i stabilnych systemów zarządzania pakietami, takich jak RPM , APT / dpkg i Portage Gentoo .

Istnieją projekty, takie jak Autopackage , które próbują rozwiązać problem, ale ciągła ewolucja różnych obsługiwanych systemów zarządzania pakietami oznacza, że ​​istnieje wiele ruchomych celów do naśladowania.

W końcu niektórzy dostawcy oprogramowania łączą określone pliki binarne i kopie zależności, których potrzebują, w jeden duży pakiet, który będzie działał w określonych systemach.

Posiadanie tego samego formatu pakietu i tak by nie pomogło. Po prostu nie możesz użyć tego samego pakietu w innych dystrybucjach. Często nie można go nawet użyć w innej wersji tej samej dystrybucji. Nawet zbudowanie pakietu może mieć te same problemy.

Aby zainstalować pakiet, musisz spełnić zależności, które powstają podczas budowania pakietu. Aby zbudować pakiet, musisz spełnić zależności kompilacji. I te rzeczy się zmieniają. Aby móc wprowadzić zmiany, łatwiej jest obsługiwać tylko te pakiety, które można zmodyfikować, aby działały po zmianach.

Jeśli wszystkie zależności byłyby takie same, nie byłaby to inna dystrybucja ani inna wersja tej samej dystrybucji.

Myślę, że jest trochę „syndromu niewymienionego tutaj”. System pakowania Debiana jest wcześniejszy niż RedHat, a mimo to jest lepszy pod wieloma względami, ale nigdy nie zobaczysz przełączania RedHata. Zamiast tego widzisz wielu ludzi używających „apt-rpm”, którzy próbują dać ci pewne zalety apt z plikami rpm.

Po prostu idź na .deb :-)

Było kilka wstępnie sformatowanych formatów, takich jak zerowa instalacja i automatyczne pakowanie . Niestety żaden nie zyskał żadnej przyczepności.

Myślę, że Cletus, Wayne i iny odpowiedzieli na to całkiem nieźle. Chciałbym dodać, że to naprawdę nie jest wielka sprawa. Pracuję w mieszanym środowisku, w którym mamy Gentoo (portage), SUSE (rpm / zypper) i OpenBSD (pakiety i porty). Instalowanie pakietów na jednym z nich nie jest trudne i nie obchodzi mnie, jakiego formatu używają.

Z punktu widzenia oprogramowania do pakowania nie jest to również zbyt trudne. Niezależnie od tego, czy jest to Gentoo, dystrybucja oparta na RPM, czy dystrybucja debowa, tak naprawdę sprowadza się to do posiadania przepisów na tworzenie oprogramowania i dodawanie metadanych. Pod warunkiem, że system kompilacji tego, co próbujesz spakować, nie jest całkowicie szalony, zwykle potrzeba niewiele więcej niż napisanie gloryfikowanego skryptu powłoki, aby utworzyć pakiet.

Cóż, zawsze są skompilowane statycznie pliki binarne w kulkach smoły .... ;-)

Nie ma definicji standardowego interfejsu binarnego dla „Linuksa”, ponieważ jest to tylko jądro. Szanse na to, że twój stos oprogramowania będzie musiał współpracować z więcej niż tylko jądrem, co stanowi szczególne wyzwanie w utrzymaniu standardowego ABI między setkami różnych drzew źródłowych.

Jeśli chodzi o dobre narzędzia do pakowania, wolę Debian GNU / Linux, ponieważ jest to doskonały format pakowania binarnego. Zaspokoiło 90% moich potrzeb w zakresie standardowych narzędzi i aplikacji. Pozostałe 10% jest zbudowane ze źródła ze względu na włączenie niewolnych komponentów lub błędnych zależności biblioteki współdzielonej. Kiedy aplikacje te muszą zostać wdrożone, tworzę niestandardowe pliki binarne dla klastrów produkcyjnych.

Aby uzyskać kompilację raz, uruchom format pakietu w dowolnym miejscu, nie zmuszając wszystkich do korzystania z tej samej dystrybucji, potrzebujesz kilku ważnych funkcji:

• Unikalne w skali globalnej nazewnictwo pakietów, dzięki czemu dwie osoby / dystrybucje nie mogą niezależnie tworzyć różnych pakietów o tej samej nazwie.

• Możliwość równoległego instalowania różnych wersji bibliotek, gdy pakiety mają sprzeczne wymagania. Dystrybucja może zdecydować, której wersji każdej biblioteki użyć, i zmusić wszystkie pakiety do korzystania z tej wersji. System działający w różnych dystrybucjach musi być bardziej elastyczny.

Instalacja zerowa zapewnia obie te funkcje:

• Nazwy to identyfikatory URI (np. Http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). Tylko właściciel domeny może domyślnie tworzyć pakiety w tej przestrzeni nazw.

• Każda wersja każdego pakietu znajduje się we własnym katalogu. Każda aplikacja widzi tylko te biblioteki, których potrzebuje, z wersjami, z którymi jest kompatybilna.

Na przykład aplikacja Edytuj zależy od Pythona <3 w następujący sposób:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

Zobacz także: http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[Uwaga: Jestem programistą 0install]