Afhængighedsproblemer i Linux

ved slackware ville det problem være løst - jeg tror det er et af deres hovedargumenter for ikke at have dependency-tracking.

Alternativt set må du kunne udpakke RPM/deb'en og med mindre der er virkeligt komplekse install-hooks, så skulle du kunne bruge dette.

Der er strengt taget ikke noget i vejen for at lægge en note ind i Slackwares READMEs, som vises, når man installerer en pakke, hvor man skriver, at programmet kræver visse deps. Men man skal jo stadig lægge dem ind.

#0:
nej du misforstår, du kan SAGTENS, jeg gentager, SAGTENS have en nyere, eller ændre version, af ting, end dem fra din distributiosn repositorier installeret, du kan bare ikke bevidst overskrive en version der er ting der afhænger af, med en ukompatibel version, du kan dog sagtens sideløbende have 100 inkompatible versioner.

#0
Jaa, det er jo så lidt ulempen/fordelen ved Linux :) Kan ikke på nogen måde se at det er Linux der har et generelt afhængighedsproblem :)

Der er jo ikke noget teknisk til hinder for at man kan bygge en statisk linket pakke med alle de nødvendige libs og ting og sager inkluderet ("duplikeret") ligesom det er tilfældet på MS Windows, med de sikkerhedsproblemer, pladsspild osv. det fører med sig. Der er bare som regel ikke rigtigt nogen der gider gøre det.

Men PC-BSD skulle efter sigende gøre noget i den stil. Har dog aldrig prøvet det eller sat mig nærmere ind i det.

#5:
der er også mange andre muligheder.

kompatibilitet brydes ikke såååå tit igen på diverse pakker, man kunne have nogle forskellige prefixes, altså for eksempel /usr/circa2006 /usr/circa2007 mm, hvor du havde et sæt forskelligt versionerede libraries og programmer installeret, separat fra pakkesystemet, eller med specialiseret pakkesystem, på denne måde kan alt holdes ved siden af hinanden uden at statisk linke eller noget som helst, og samtidig opretholde fordelene ved et pakkesystem

#6 - det kunne man, men det er ikke sådan man gør.

Der er allerede indbygget versionering mht. shared libraries i Linux via formatet ELF som bruges til objekt filer, shared libraries samt program-filer.

I korte træk har et ELF-program en række dynamiske strukturer kaldet DT_NEEDED, en for hver library programmet afhænger af. Som udgangspunkt er denne streng blot en sti, fx /lib64/libc.so men det kan også godt være et vilkårligt navn.

Grunden hertil er at et shared library selv kan have en DT_SONAME struktur, som groft sagt angiver et navn denne udgave af biblioteket ønsker at refereres ved (our name is Legion, for we are many :P ) - i så fald vil programmet ikke referere til biblioteket med en sti, men dette 'soname'.

Man kan derfor lave en ny revision af et bibliotek som er inkompatibelt med de ældre revisioner og give dette et nyt SONAME, dette medfører at programmerne som afhænger af en ældre udgave af biblioteket kan lede efter en given version, som har det korrekte 'soname'.

And there you have it.

Hvis man vil vide mere så kan ELF 1.1/1.2 specifikationerne(2-13 & 2-15 i 1.1) eller "The Linux Programming Interface" af Michael Kerrisk (~840) konsulteres.

PS!
I praksis er det så kotume i Linux at opdateres et bibliotek på en sådan måde at det er inkompitabelt med ældre versioner, så rev'er man MAJOR versionsnummeret mens alle opdateringer der ikke bryder kompatibilitet får deres MINOR version nummer rev'ed.
Men det er faktisk ikke filnavnene og deres sti som virkeligt gælder (kun såfremt DT_SONAME ikke er angivet hvilket er undtagelsen snarere end reglen da man i så fald ikke kunne henvise til libraries i andre stier end den sti som blev angivet @ link time - det ville fx umuliggøre brugen af LD_LIBRARY_PATH til at override biblioteker)

#5: Der er jo ikke noget teknisk til hinder for at man kan bygge en statisk linket pakke med alle de nødvendige libs og ting og sager inkluderet ("duplikeret") ligesom det er tilfældet på MS Windows, med de sikkerhedsproblemer, pladsspild osv. det fører med sig.Det er nu ikke nogen definitiv sandhed. Se her og her. Og dynamisk linking har bestemt også sikkerhedsproblemer.

marlar: Jeg forstår ikke helt din kritik. Er det ikke meget logisk at det er problematisk hvis to programmer afhænger af forskellige versioner af det samme bibliotek? Den eneste løsning til det problem er noget som GoboLinux/0-install/lign. eller programmer der inkludere alle deres deps (bundles ala OS X eller static linking).

#1: ved slackware ville det problem være løst - jeg tror det er et af deres hovedargumenter for ikke at have dependency-tracking.Hvad? Hvordan skulle manglende dependency tracking kunne løse det problem? Apropos, jeg har aldrig hørt noget tiltalende argument, for ikke at lade package manageren håndtere dependencies).

#7:
ganske korrekt, men dette holder kun stik for libraries, ikke programmer, som jo altid har kotume for at have samme binær navn, og alle de platformsuafhængige resourcer under samme navn, trods det meget ofte er forskelligt.

desuden gav jeg svar på hvordan marlar selv kan gøre det han vil med at installere alle programmer under himlen, uden at skulle modificere samtlige projekter som ikke fatter at skifte version ved inkompatibilitet.

en af årsagerne til dette er jo også at ikke alle udviklere altid er lige enige om hvornår en version skal inkrementeres og gøres "ukompatibel", mange af de libs der har problemerne er jo source kompatibel men ikke abi kompatibel, og hvis du så bare dumper et nyt library ind har du jo præcist samme problem, selvom du sagtens kunne bygge dit system op ud fra den version.