Zastanawiam się, czy teoretycznie jest możliwe zbudowanie dystrybucji Linuksa, która może obsługiwać zarówno pakiety RPM, jak i Debian.

Czy istnieją jakieś dystrybucje, które obsługują oba?

A jeśli nie, czy to w ogóle możliwe?

Bedrock Linux to robi. Nie mówię, że to zrobiłem, lub że to dobry pomysł, ale jest już robiony.

Nie sądziłem, że istnieją jakieś dystrybucje, które wspierają oba natywnie, ale okazuje się, że jest jedna w fazie rozwoju, Bedrock Linux (dzięki iMalinowski za informację). W innych dystrybucjach możesz użyć narzędzi do konwersji, takich jak alienkonwersja z jednego formatu na drugi. Wszystko, co jest oparte na oprogramowaniu, jest wykonalne, biorąc pod uwagę wystarczającą ilość czasu i energii, więc byłoby możliwe zbudowanie takiej dystrybucji (ale biorąc pod uwagę różnice między możliwościami .debi .rpmpakietami, dość trudne).

Jednak wszystko to prawdopodobnie wynika z pomysłu, że obsługa obu formatów pakietów uprościłaby życie, ponieważ można było wtedy instalować pakiety z dowolnego miejsca (cóż, gdziekolwiek z zapewnieniem .deblub .rpm). Filozoficznie to wada. Dystrybucja to spójny zestaw pakietów; jeśli chcesz dostarczyć oprogramowanie dla tej dystrybucji, naprawdę musisz specjalnie do niego ukierunkować, co obejmuje użycie jego formatu pakietu (i, co ważniejsze, metadanych). Nie ma sensu wspierać natywnie wielu formatów pakietów.

(W świecie Debiana pakiety mogą działać na wariantach, które nie są ich głównym celem, ponieważ nomenklatura pakietów jest raczej jednorodna, a większość dystrybucji mieści się w drzewie dziedziczenia. Nie jest to prawdą w świecie RPM. W obu przypadkach mieszanie i dopasowanie to zły pomysł.)

Powinieneś rozważyć swoją dystrybucję jako podstawę do zbudowania pożądanego systemu, przestrzegając zasad i ekosystemu dystrybucji, bez mieszania rzeczy z innych dystrybucji. Potrzebne są abstrakcje wyższego poziomu do obsługi miksowania i dopasowywania (a raczej w celu zapewnienia środowisk dla wielu dystrybucji): środowisko uruchomieniowe Steam, Flatpak itp.

Nie, takiego potwora nie należy budować. W przeciwieństwie do, powiedzmy, pakietu aplikacji MacOS, który zazwyczaj zawiera wszystko, co aplikacja musi uruchomić w systemie operacyjnym, pakiety RPM i .deb prawie zawsze zależą od innych pakietów, takich jak biblioteki współdzielone. Pakiety systemu Linux zawierają listę innych pakietów, które muszą być obecne, a menedżer pakietów pomaga egzekwować te wymagania. Co więcej, dystrybucje Linuksa różnią się sposobem działania (np. /etc/network/interfaces.dVs. /etc/sysconfig/network-scripts).

Nie powinieneś nawet mieszać pakietów z dowolnych repozytoriów w tej samej rodzinie formatów pakietów. Oznacza to, że instalowanie pakietów SuSE na maszynie CentOS wymaga jedynie kłopotów, mimo że oba używają RPM. Nie instalowałbym nawet pakietów przeznaczonych dla innej wersji tego samego systemu operacyjnego (np. Pakiety Ubuntu 14.04 w systemie 16.04), chyba że wiedziałbym dokładnie, co robię.

Zatem próba obsługi zarówno RPM, jak i .deb w tym samym systemie nie wchodzi w rachubę. W niektórych desperackich sytuacjach można konwertować określone pakiety przy użyciu alien, ale należy się spodziewać, że włożymy wiele wysiłku w rozwiązywanie problemów, które nieuchronnie wynikną z takich włamań.

Cóż, istnieje alien( strona podręcznika ), które można konwertować między rpm, debitp., Ale zakładam, że rzeczywiste problemy wynikają z obsługi zależności (różne nazwy pakietów dla oprogramowania) i lokalizacji plików konfiguracyjnych.

Oczywiście, jeśli masz na myśli, że oba typy pakietów mogą pochodzić z samej dystrybucji, można by to obejść, ale dlaczego ktoś miałby to zrobić ... (I nadal musiałbyś przekonwertować wszystko na jedno lub drugie , ponieważ nie sądzę, aby dpkgwiedział, jak czytać bazy danych rpmi vice versa.)

Tak, jest to możliwe, ale rujnuje dystrybucję.

Pakiety to nie tylko format, który można łatwo przenosić z jednego formatu na drugi.

Uwaga: narzędzia do instalacji pakietów muszą być przeniesione, ponieważ chciałoby się mieć scentralizowaną listę wszystkich pakietów, wersji, zależności, plików konfiguracyjnych, skryptów przed i po instalacji (jeśli zamienisz jeden pakiet na inny, w innym pakiecie w formacie, należy się spodziewać, że skrypty deinstalacyjne (stary format) są uruchamiane z nowego systemu pakietów.

Ale dystrybucja i pakiety to znacznie więcej niż format pakietów. Np. Dla Debiana: chcemy umieścić pliki we właściwym miejscu, chcemy udostępnić stronę podręcznika, chcemy mieć wspólne skrypty demonizujące, chcemy, aby program działał w wielu architekturach, w różnych środowiskach graficznych, aby użytkownik znalazł sam zna wewnątrz dystrybucji także nowe pakiety. pakiety.

W Debianie chcemy, aby pakiety były łatwe do zbudowania przez użytkowników (ze źródeł), aby można było dostosować niektóre ważne (dla niego) pakiety. Wymaga to dużej infrastruktury, której większość autorów nie może zapewnić (automatyczne budowanie i testowanie na różnych architekturach i wykonywane od czasu do czasu). Ponadto specyficzne dla Debiana są wymagania licencji, aby łatwiej było rozwidlać pakiet lub dystrybucję, bez konieczności sprawdzania wszystkich pakietów.

Na koniec dystrybucja odbywa się za pomocą spójnych pakietów, a nie tylko pakietów.

Tak i większość dystrybucji opartych na .deb już to robi, ale ...

Na Debianie i pokrewnych rodzinach masz przynajmniej to alien, co pozwoli ci zainstalować pakiety RPM.

Te same problemy będą występować, gdy miksujesz pakiety, które nie zostały zaprojektowane do pracy z dystrybucją, instalując pakiety obce niezależnie od formatu - jeśli zainstalujesz RPM w systemie opartym na DEB, to RPM musi być kompatybilny z twoim systemem , tak jakbyś instalował pakiet RPM w systemie opartym na RPM, i to jest to. Możesz to zrobić, ale prawdopodobnie nie chcesz.

Tak i nie. deb i rpm to tylko formaty. Możesz obsługiwać oba formaty, ale jest to bezcelowe. Pakiety zasadniczo nie są porównywalne między dystrybucjami, zwłaszcza dystrybucjami, które nie są oparte na sobie.

Gdyby wszystkie dystrybucje miały takie same wymagania dotyczące wersji, to cała dystrybucja byłaby wyborem pakietu. Możesz zainstalować dowolną dystrybucję, wyświetlając listę pakietów.

Ale dystrybucje muszą zapewniać oprogramowanie, które mogą obsługiwać. Jeśli biblioteka, która sprawia, że ​​aplikacja działa, nie jest utrzymywana i sama wymaga biblioteki, która została zastąpiona przez coś innego, jak rozwiązać ten konflikt? Menedżer pakietów nie może przenieść kodu. Może być wielu następców wybranych przez różne dystrybucje do.