Linux - piekło zależności - jakie są przyczyny

Odpowiedz Nowy wątek
2016-08-13 23:08
0

Witajcie

Wikipedia podaje:

Piekło zależności (ang. Dependency hell) – potoczny termin określający błędnie zdefiniowane lub trudne do spełnienia zależności, uniemożliwiające lub utrudniające instalację oprogramowania.

Trudne do spełnienia zależności występują na przykład w wypadku instalowania dwóch aplikacji, z których każda wymaga innej wersji tego samego programu (oba są od niego zależne).

1)Dlaczego biblioteka która jest niezbędna DANEJ aplikacji jest instalowana w systemie? Czy nie powinna być ona tak jakby z plikiem wykonywalnym - jak na Windows - gdy potrzebuje SFML to dołączam niezbędne .dll'ki do folderu z .exe i się nie martwię jakimiś zaleznościami.
Jeżeli aplikacja wymaga SFML 1.6 to ma ze sobą *.dll'ki SFML 1.6.

Albo gdy aplikacja wymaga starej wersji np glibc czy jakieś innej biblioteki - powinna ją zlinkować statycznie lub mieć ze sobą razem z plikiem wykonywalnym.

2)Jeżeli chodzi jeszcze o zależności - podkreśliłem ten fragment definicji z Wikipedii:

dwóch aplikacji, z których każda wymaga innej wersji tego samego programu

Czy to możliwe że aplikacja wymaga serwera X w wersji 123.45 a druga aplikacja potrzebuje do działania serwera X w wersji 234.56 ?
Jeżeli tak to jak ten problem został rozwiązany na Windowssie - mi się nigdy nie zdażyło by aplikacja mówiła Twój Windows ma zbyt nowoczesny menadzer okien ;)


Jeśli mój post jest dowodem mojej niekompetencji, to trudno, ale po to pytam, żeby się czegoś dowiedzieć.
edytowany 1x, ostatnio: kacper546, 2016-08-13 23:13

Pozostało 580 znaków

2016-08-13 23:15
0

Czy nie powinna być ona tak jakby z plikiem wykonywalnym

Pod Linuksem właściwie nie ma czegoś takiego jak "jakby z plikiem wykonywalnym". Wszystko, każda najmniejsza pierdoła, jest instalowane w /bin albo w /usr/local/bin.
Choć teoretycznie możliwe jest by każdy program miał osobny katalog jak pod Windows, to tak jednak się nie robi.

edytowany 1x, ostatnio: Azarien, 2016-08-13 23:18
To tradycja czy decyzja projektowa, a moze zaszłości z czasów gdy Linux był tylko na serwerach? - kacper546 2016-08-13 23:53
A kiedy Linux był tylko na serwerach? Przecież początkową ideą Linuksa było bycie darmową wersją Uniksa na komputery domowe. - somekind 2016-08-14 03:34

Pozostało 580 znaków

2016-08-14 05:07
Mały ludek
0
kacper546 napisał(a):

1)Dlaczego biblioteka która jest niezbędna DANEJ aplikacji jest instalowana w systemie?

Nieprawda, jak najbardziej można dystrybuować aplikację wraz z wymaganymi bibliotekami, oraz umieszczać biblioteki dynamiczne w dowolny katalogu (z wykorzystaniem zmiennej środowiskowej LD_LIBRARY_PATH)

kacper546 napisał(a):

Albo gdy aplikacja wymaga starej wersji np glibc czy jakieś innej biblioteki - powinna ją zlinkować statycznie lub mieć ze sobą razem z plikiem wykonywalnym.

Z glibc to akurat może być problem - jeśli masz za stary aplikacja może wymagać "update systemu". Większość innych bibliotek, albo można linkować statycznie, albo można dystrybuować z aplikacją.

kacper546 napisał(a):

Czy to możliwe że aplikacja wymaga serwera X w wersji 123.45 a druga aplikacja potrzebuje do działania serwera X w wersji 234.56 ?

Teoretycznie możliwe, ale do rozwiązania. Można np. postawić dwie instancje danego serwera.

Azarien napisał(a):

Czy nie powinna być ona tak jakby z plikiem wykonywalnym

Pod Linuksem właściwie nie ma czegoś takiego jak "jakby z plikiem wykonywalnym". Wszystko, każda najmniejsza pierdoła, jest instalowane w /bin albo w /usr/local/bin.
Choć teoretycznie możliwe jest by każdy program miał osobny katalog jak pod Windows, to tak jednak się nie robi.

W przeciwieństwie do tego co kolega mówi to w Linuxie są pliki wykonywalne. Mogą a często są umieszczane w innych katalogach niż wspomniane.
Proponuje katalogi /bin oraz /usr/local/bin potraktować analogicznie jak c:\Windows\ oraz c:\Program Files` na Windowsach - większość aplikacji jest tam instalowana, ale nic nie stoi na przeszkodzie aby instalować gdzie indziej.

Pozostało 580 znaków

2016-08-14 09:01
0

Na dzień dzisiejszy jest to problem raczej teoretyczny, ponieważ:

mamy rozwinięte menadżery pakietów. Ja korzystam z Debiana w domu, a w pracy na serwerach z Red Hata. I w *.deb jest coś takiego, że wypisuje się po prostu wersję niezbędne do działania. Jest np. taki program debreate w którym można dosyć szybko się tego nauczyć i tworzyć własne *.deb: http://debreate.sourceforge.net .
Problem pojawia się gdy paczka A wymaga paczki B a ta wymaga paczek C,D,E,F. Generalnie im bardziej skomplikowany soft, tym trudniej spaczkować i dobrać czego brakuje.

W teorii wygląda to tak, że początkowy problem zależności (a także ich update) powinien być rozwiązany przez managery pakietów.
I są to dobre narzędzia, ale ludzie z nich różnie korzystają: czasami wypiszą złe wersje, czasami nie wypiszą wszystkiego, a czasami wypiszą coś czego nie ma w repozytoriach.
Jednak w świecie idealnym problem zależności powinien zostać rozwiązany przez menadżery pakietów z których idealnie korzystają ludzie.

W takim Debianie mamy porządek i raczej rzadko czegoś brakuje, ale oczywiście jak trzeba skompilować ze źródeł coś czego nie ma w repozytorium, to już muszę przeanalizować te zależności.
Dla osoby zwykłej: im lepiej ktoś chce zarządzać zależnościami, tym lepiej musi znać swój manadżer pakietów i repozytoria. Wraz z doświadczeniem problem ten znika.

Na serwerach prod. mają Red Haty i na poważnym serwerze bardzo rzadko coś się instaluje, co zagraża stabilności systemu (np. najpierw się sprawdza na testowych platformach). Sys-admini siedzą całymi dniami i analizują problemy update-ów. Więc są ludzie od tego.

edytowany 7x, ostatnio: aurel, 2017-10-09 19:42

Pozostało 580 znaków

2016-08-14 11:04
0
Mały ludek napisał(a)

W przeciwieństwie do tego co kolega mówi to w Linuxie są pliki wykonywalne.

Nie napisałem że nie ma plików wykonywalnych, tylko że nie ma czegoś takiego jak "katalog aplikacji" w którym byłyby wszystkie pliki z nią związane, tak jak to jest pod Windowsem.

Jest, przyjęło się taki katalog w uniksach nazywać /opt - mlyszczek 2016-08-14 11:09
jakby tak było i tego się trzymano, to nie byłoby tego wątka :-) - Azarien 2016-08-14 11:11
Ten wątek jest, bo OP używa jakiejś dziwacznej dystrybucji z jakimś kiepskawym menadżerem pakietów;-) No i jaki jest wtedy sens posiadania dynamicznych bibliotek jak każdy program korzysta ze swojej kopii z /opt. Po to libki są trzymane w lib a programy w bin, aby program nie zajmował 20mb w ramie tylko 10. - mlyszczek 2016-08-14 11:18

Pozostało 580 znaków

2016-08-14 11:29
Zibiiiii
0

@mlyszczek to chyba ty używasz dziwacznej dystrybucji, skoro menedżer pakietów z oficjalnego repo ładuje ci pliki do /opt i to jeszcze do podkatalogów. Jak długo zyję, jeszcze takich cudów nie widziałem (debian, ubuntu, redhat, centos)

Pozostało 580 znaków

2016-08-14 11:34
0

1)Dlaczego biblioteka która jest niezbędna DANEJ aplikacji jest instalowana w systemie? Czy nie powinna być ona tak jakby z plikiem wykonywalnym - jak na Windows - gdy potrzebuje SFML to dołączam niezbędne .dll'ki do folderu z .exe i się nie martwię jakimiś zaleznościami.
Jeżeli aplikacja wymaga SFML 1.6 to ma ze sobą *.dll'ki SFML 1.6.

Albo gdy aplikacja wymaga starej wersji np glibc czy jakieś innej biblioteki - powinna ją zlinkować statycznie lub mieć ze sobą razem z plikiem wykonywalnym.

Współdzielenie bibliotek pozwala nie tylko zmniejszyć wykorzystanie dysku, ale też RAMu. Producenci programów Windowsowych wybrali inny model dystrybucji, pewnie dlatego, że na Windowsie na ma żadnego menedżera pakietów.

Z drugiej strony, na Windowsie też jest problem z różnymi wersjami bibliotek naraz mimo, że producenci i tak zwykle wrzucają DLLki obok EXEków. Jest coś takiego jak "Microsoft Visual C++ Redistributable" i zwykle jest to zainstalowane w wielu kopiach na jednym komputerze: Why Are There So Many “Microsoft Visual C++ Redistributables” Installed on My PC?

Czy to możliwe że aplikacja wymaga serwera X w wersji 123.45 a druga aplikacja potrzebuje do działania serwera X w wersji 234.56 ?
Jeżeli tak to jak ten problem został rozwiązany na Windowssie - mi się nigdy nie zdażyło by aplikacja mówiła Twój Windows ma zbyt nowoczesny menadzer okien ;)

Nie zdarzyło ci się, że aplikacja się nie uruchomiła bo masz zbyt nowoczesnego Windowsa? No to chyba mało aplikacji odpalasz ;) Jest mnóstwo staroci, które chodzą na starych Windowsach, a na nowych ich nijak nie odpalisz.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2016-08-14 11:40
Jest menedżer pakietów dla Windowsa- Chocolatey/ OneGet. - Phestek 2016-08-14 12:18
Jaki % zainstalowanych programów go używa? - Wibowit 2016-08-14 12:32
Żaden, ale to nie znaczy, że menedżer pakietów dla Windowsa nie istnieje. To tak, jakbyś powiedział, że Korwin nie istnieje, bo nie ma go w sejmie. - Phestek 2016-08-14 12:36
Chodziło mi o to, że w Windowsie nie ma wbudowanego menedżera pakietów, więc nie można polegać na jego obecności. Przynajmniej przed Windowsem 10, bo z tego co na szybko wyczytałem to ten OneGet jest nową funkcją Windowsa 10. "Trochę" zbyt późno się pojawił, by traktować zarządzanie zależnościami jako coś typowego dla Windowsa. - Wibowit 2016-08-14 12:42

Pozostało 580 znaków

2016-08-14 11:48
0
Wibowit napisał(a):

Jest coś takiego jak "Microsoft Visual C++ Redistributable" i zwykle jest to zainstalowane w wielu kopiach na jednym komputerze

i bywa, że każda aplikacja wymaga innej wersji, a i wersji 32 lub 64 bit więc mamy podwójny bonus :)


Pozostało 580 znaków

2016-08-14 11:53
2

oczywiście dodam, że to nie tylko problem "Linuxa", ale szerszy co do oprogramowania:

PHP i composer ?

Python i pip ?

NodeJS i npm ?

Ruby i gemy?

Perl i cpan ?

wszędzie w oprogramowaniu jest ten problem ;)
(według mnie najprzyjemniejszy i największy porządek jest w Ruby, później PHP composer, później Python, a na końcu NodeJS... zawsze Ruby najmniej problemów miał :D... ale to tylko subiektywna opinia)

generalnie nie da się pisać oprogramowania bez systemu zależności/bibliotek/paczek/dodatków/modułów/klas (jak zwał tak zwał).

edytowany 4x, ostatnio: aurel, 2017-10-09 19:42
dobrze kombinujesz i poruszyłeś dobrze problem. paradoksalnie przy tych pseudonarzędziach jak npm, które są żałosne to maven jak dla mnie bije je wszystkie na głowe. - karolinaa 2016-08-14 12:37

Pozostało 580 znaków

2016-08-14 13:49
Czarny Pomidor
0

No popatrz, a ja najwięcej problemów z zależnościami i pakietami miałem pod RoR i gem i tym rvm. Ciągle jakieś błędy pod Linuksem. Za to najlepiej działa mi pip, jak widzisz inna dystrybucja i inny problem. Z Node,js i npm też nie miałem problemów, używam dystrybucji Archo podobnych.

hahaha, to ja dodam, że za każdym razem jak coś chciałem z npm, to mi wysiadały właśnie zależności :D NodeJS kojarzy mi się z takim bałaganem, że bardziej się nie da - ale to było z pół roku temu. - NieGooglujMnie 2016-08-14 15:00

Pozostało 580 znaków

2016-08-14 15:18
1

Trzy ciekawostki w tym temacie:

  1. dla Linuxa jest projekt, który naśladuje manager pakietów z OSX:
    https://github.com/Linuxbrew/brew

nazywa się to "Linuxbrew", jest odpowiednikiem homebrew ( http://brew.sh ) .
https://en.wikipedia.org/wiki/Homebrew_(package_management_software)

generalnie linuxbrew krytykowany jest za zmniejszenie bezpieczeństwa (kwestia uprawnień i wrzucanie wszystkiego do $HOME), ale wydaje mi się dosyć ciekawym rozwiązaniem:
"It can be installed in your home directory and does not require root access. The same package manager can be used on both your Linux server and your Mac laptop."
W wolnym czasie warto sobie posprawdzać jakie pakiety są w środku (adekwatne do homebrew) : http://braumeister.org

  1. największym problemem z utworzeniem "Linux From Scratch" (stawianie Linuxa od 0) jest właśnie zaaplikowanie jakiegoś sensownego managera pakietów.
    Generalnie dużo osób dochodziło do momentu, że stawiali swojego LFS, ale nie umieli zarządzać późniejszymi zależnościami. Pojawiał się koszmar przy update.
    Teoretycznie gdyby napisać swój manager pakietów (np. coś na Pythonie opartego), to dałoby się stworzyć oddzielną dystrybucję Linuxa, bo tak naprawdę system Linux to jest kernel + manager pakietów.

  2. Slackware ma na tyle ogólne pakiety : https://slackbuilds.org
    że można próbować to instalować na każdym Linuxie, w sensie, że korzystać z tego repozytorium, np taki fork:
    https://github.com/Ponce/slackbuilds
    Można to próbować instalować na dowolnej dystrybucji, bo jest dosyć spora kompatybilność tego repozytorium wobec całego Linuxa
    (oczywiście tutaj upraszczam, ale generalnie pakiety Slackware są bardzo kompatybilne wobec całego Linuxa)
    Swoją drogą - bardzo dobrym pomysłem byłoby utworzenie bezpośrednio repozytorium właśnie w całości opartego na GitHub + Git , według mnie rozwiązałoby to sprawę zależności (wszystko na GitHub).

edytowany 5x, ostatnio: aurel, 2017-10-09 19:42

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0