Afhængighedshelvedet i Linux

Problemet med package-managers og "everything and the kitchen sink" mentaliteten.

perl-json lyder som et forholdsvist populært stykke kode til perl og derfor er jeg 100% sikker på du kan installere det direkte gennem CPAN.

Perl (såvel som Python og Ruby, og NodeJs) har deres egne pakke-managers som du med fordel kan benytte :)

Det er jo dér, de sourcebaserede kommer til deres ret - når de spørger, om man vil inkludere deps også. Det er grunden til, at jeg i lang tid kørte med Lunar Linux. Den havde en lang række valgfrie deps, så man slap for en masse crap. Det betyder selvfølgelig, at man skal have noget lidt kraftigere jern at køre den på, end jeg har.

#2:
I den kategori har vi også Sourcemage, der er en voldsomt interessant distro. Slackware løser vel også problemet til dels i kraft af at alle pakkeinstallationer er "frivillige".

Jeg synes aldrig jeg oplever den slags problemer? Jeg bruger selvfølgelig også Fedora, så kan godt være at den ikke er så ramt af problemet.

prøv med apt-get har aldrig haft gode erfaringer med aptitude.

Ofte når det sker er problemet du har blandet repositories fra forskellige distro's eller versioner af samme distro.

michael@michael-pc:~$ sudo apt-get install libjson-perl
[sudo] password for michael:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libcommon-sense-perl libjson-xs-perl
The following NEW packages will be installed:
libcommon-sense-perl libjson-perl libjson-xs-perl
0 upgraded, 3 newly installed, 0 to remove and 67 not upgraded.
Need to get 196 kB of archives.
After this operation, 612 kB of additional disk space will be used.
Do you want to continue [Y/n]?

Tror der er noget galt med din installation ;)

Har heller ikke lige de problemer. Her på Debian Wheezy.

aptitude install libjson-perl
The following NEW packages will be installed:
libcommon-sense-perl{a} libjson-perl libjson-xs-perl{a}
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 213 kB of archives. After unpacking 544 kB will be used.
Do you want to continue? [Y/n/?]

Der er to problemer der skal løses i denne tråd.

Den første er, at vores package managers i dag ikke er fleksible nok. Der kan ikke (umiddelbart) installeres forskellige versioner af samme programmer og libs - og konfliktende pakker kan ikke installeres side om side.

Den andet problem er vore distro-siloer. Der er noget helt galt, når vi konstant skal sige til folk at de skal prøve distro x, y og z, hvor problemet er blevet rettet. Pga. at den nuværende struktur i linux-økosystemet finder upstreamning desværre ikke sted.

Begge to er problemer, som gnome os specifikt vil forsøge at løse.

#0

Jeg kan kun være enig med #8, men jeg forstår ikke rigtigt Marlars problem, med mindre som nævnt, at ekstra repos er tilføjet, måske i LMDE.

Så vidt jeg husker, så udskiftede Marlar Linux Mint Debian med Mint 13, eller handlede det om dualboot mellem LMDE og Mint 13? Ret mig hvis jeg tager fejl.

Jeg har så installeret libjson-perl på Mint 13 uden problemer, heller ikke med afhængigheder, så der må være et eller andet Marlar mangler at informere?

#0+#4
Jeg vil også mene at "afhængighedshelvede" er noget man kun oplever hvis man bruger uofficielle og/eller inkompatible repositories, eller hvis man forsøger at installere pakker man har downloadet manuelt et eller andet sted, som ikke er bygget specifikt til ens distro(-version).

Men selvfølgelig er det ikke alle pakker man kan få via officielle repos, men jeg vil nu mene at man skal ud i nogle hjørner og nicheområder først.

#8
Nogle gange kunne jeg godt drømme om at applikationsudviklerne ikke var så forhippede på altid at kræve de nyeste nye libs. Hvis de tænkte bare en smule på "bagudkompatibilitet"/"backportabilitet" og packaging-venlighed, når de skrev deres programmer kunne de spare distros og brugere for meget bøvl - og dermed også få mange flere brugere af deres programmer. Men det er selvfølgelig nemt for mig at sige.

Det ville også være trist at skulle ud i et MS Windows-agtigt setup hvor man havde 10 forskellige versioner af de samme libs installeret, fordi hvert enkelt program bundlede hele lortet.

Er det bedre, at copy/paste kode i alle moduler frem for bruge den samme kode i et lib af nylig dato? Det vil jeg ikke mene. Jeg har selv haft den tvivlsomme glæde af at maintaine kode, hvor vi havde ifdef's i lag-på-lag for at opretholde support mod flere års gamle libs. Det ender med at koste rigtig meget tid. Både på udviklingen fordi kodens kompleksitet stiger for hvert release - derudover er testfasen meget mere tidskrævende. Hvis man siger at man supporter noget, så skal det også testes før release. Med support for 3-4 versioner af 4-5 forskellige libs, så giver det _mange_ kombinationer der skal testes. Det var ikke tid jeg satte pris på. Desuden er det meget sjældent, at f.eks. en distro der shipper flere års gammel version af gtk+ pludselig vælger at opdatere til gnome 3.6.

Derudover skal vi tænke på hvad en uafhængig softwareudvikler gerne vil bruge. Hvis de gerne vil bruge et lib af en nyere (eller bare specifik) version, så er det rigtig træls at det kun kan installeres på en distro der har en holdbarhed på typisk ½år. Det holder ganske enkelt ikke.

Det skal selvfølgelig være sagt, at det ikke er optimalt at skulle opretholde sikkerheden på flere versioner af samme lib. Det er dog ikke et uoverkommeligt problem. Dels fordi libs (og libs-versioner) bliver "rullet ud" som et hardlink hvis det allerede er installeret. Derudover vil der komme en centraliseret updater, som holder alle libs i systemt opdaterede. Det bliver derfor ikke det samme cowboy-show som i windows, hvor der jo er frit slag til at installe alt hvad man vil. I gnome os vil der stadig være en "bundle manager" som sørger for at rulle tingene ud, installere ikoner, sætte hardlinks op til libs, osv osv. Det vil derfor blive et "kontrolleret" system ala det vi kender i dag, bare med en større fleksibilitet og med mere frihed til at have flere versioner af same program og/eller lib installeret på samme tid.

Det er naturligvis en stor (teknisk/implementations-detalje) ændring i forhold til i dag, men for brugeren vil det blive en stor forbedring. Programmerinstallationer bliver nu universielle og kan hentes fra nettet i stedet for via en pakkemanager. Krav om versioner af libs forsvinder, så en åregammel distro-install vil stadig kunne installere evt. programbundles hentet fra nettet.

#1: Perl (såvel som Python og Ruby, og NodeJs) har deres egne pakke-managers som du med fordel kan benytte :)

Tak for info. Kendte ikke til CPAN. Men ja, en manuel installation af lib'en ville nok løse problemet.

#5: prøv med apt-get har aldrig haft gode erfaringer med aptitude.

Jeg foretrækker normalt aptitude fordi det netop er bedre til at løse konflikter. Ved at trykke "e" (for examine) kan man steppe igennem en række forskellige løsningsmodeller, hvor jeg da også fandt en der ikke krævede afinstallation af noget, men blot fastholdelse af nogle pakker.

For eksperiments skyld afinstallerede jeg lige og prøvede med apt-get, men den vil slet ikke. Den skriver bl.a.

Følgende pakker har uopfyldte afhængigheder:
libglib2.0-0 : Ødelægger: gnome-control-center (< 1:3) men 1:2.30.1-3 forventes installeret
network-manager : Anbefalede: crda men den bliver ikke installeret
Ødelægger: network-manager-gnome (< 0.9) men 0.8.4-3 forventes installeret


Og så stopper den bare.

Det skal retfærdigvis siges at min LMDE er fubar (hvilket også er derfor jeg har skiftet til Mint 13 på min stationære, men det her er min bærbare) og det har ganske sikkert noget med det at gøre. Men jeg har haft lignede problemer før, også på andre end LMDE.

#8: Den første er, at vores package managers i dag ikke er fleksible nok. Der kan ikke (umiddelbart) installeres forskellige versioner af samme programmer og libs - og konfliktende pakker kan ikke installeres side om side.

Helt enig! Fra min tid i Windows ( fra og med version 2.11! ) har jeg været vant til at jeg sagtens kunne have flere version af samme programmer kørende. For det første kommer mange programmer med deres egne dll'er og er således ikke afhængig af at de er installeret på systemet, og for det andet så kan man bare lægge en ældre/nyere version af en dll i programmets mappe hvorefter den ikke behøver at søge i systemmapperne (fx windows eller system32). På den måde går det fint at have flere versioner.

I Linux synes jeg ikke det er så simpelt. For det første er det ikke ligetil at hente de rigtige moduler/libs (men jeg kendte dog ikke CPAN), og for det andet er det heller ikke så ligetil hvor man så skal lægge dem! I Linux spreder programmer sig over en mængde mapper hvilket jeg egentligt finder ret irriterende. Jeg har programmeret professionelt til Windows i mange år, og jeg sætter en ære i at samle så meget som muligt i programmets egen mapper, og helst det hele. Det tillader nemlig migration ved blot at flytte/kopiere mappen.

#9: Jeg kan kun være enig med #8, men jeg forstår ikke rigtigt Marlars problem, med mindre som nævnt, at ekstra repos er tilføjet, måske i LMDE.

Så vidt jeg husker, så udskiftede Marlar Linux Mint Debian med Mint 13, eller handlede det om dualboot mellem LMDE og Mint 13? Ret mig hvis jeg tager fejl.

Som nævnt er min LMDE fubar, så det er meget muligt der er tilføjet ekstra repos. Min stationære har Mint 13, men min bærbare kører stadig LMDE. Det er på min bærbare jeg har problemet.

#10: Det ville også være trist at skulle ud i et MS Windows-agtigt setup hvor man havde 10 forskellige versioner af de samme libs installeret, fordi hvert enkelt program bundlede hele lortet.

Hvorfor egentligt det? Plads og båndbredde er billigt, men tid til at få skidtet til at fungere er dyr :)

#11: Derudover skal vi tænke på hvad en uafhængig softwareudvikler gerne vil bruge. Hvis de gerne vil bruge et lib af en nyere (eller bare specifik) version, så er det rigtig træls at det kun kan installeres på en distro der har en holdbarhed på typisk ½år. Det holder ganske enkelt ikke.

Korrekt. Og her er også en temmelig stor forskel i forhold til Windows: Jeg bruger stadig XP uden de mindste problemer. Den er tussegammel, men kører både ny og gammel software perfekt. Jeg er sikker på at man kan komme ud for det, men jeg har til dato ikke oplevet et program der ikke installerer og kører fint på XP. Ja, de kører vist fint fra og med Windows 2000. I Linux er man ret lost med en gammel distro. Hvilket jo præcis er årsagen til at jeg prøvede en rullende distro som LMDE, men den havde bare for mange børnesygdomme, så jeg gav op til sidst. [Men har dog endnu ikke haft tid at reinstallere min bærbare]

#8: Der kan ikke (umiddelbart) installeres forskellige versioner
Exherbo? Bedrock linux ? mener os gentoo kan, men ikk sikker...

http://nixos.org/nix/

http://roscidus.com/0mirror/

http://www.0install.net/

#13: mener os gentoo kan, men ikk sikker...
Det kan den. De kalder det slots, og pakkemanageren holder selv styr, hvilke versioner af et lib der skal installeres, samt hvornår en bestemt version ikke længere er benyttet og kan fjernes.

#15 mente nok, blev bare lige i tvivl. ellers er der også funtoo. Så der er et par stykker der kan klare dette :D

Marlar

Forklaringen er formentlig sammenblandede repos af stable og testing i LMDE, som det også er nævnt.

Nu vi taler om apps fælles libs, dll's med flere, så var det tidligere et problem i Win, hvor det ikke var ualmindeligt at man fik fejl ved nogle program afinstalleringer. En dll bruges af andre programmer osv, men fordelen ved brug af fælles libs er på den anden side mange, hvis afhængighedsproblemet er løst på anden vis.

Ulempen med ikke-fælles-libs og udvidelser, hvor programmer selv medbringer dem, er til gengæld bl.a.:

- Større programmer og ofte langt mere harddiskforbrug, og som følge af det, et langsommere system. Formentlig også programmernes sikkerhed.

Jeg kan kun konstatere at problemerne virker løst, og fordelene eksempelvist er, hvor disse forehold spiller sammen:

- Mindre programmer og hurtigere opdatering
- Hurtigere OS på alle områder, deriblandt opstart og nedlukning.
- Langt mindre system inklusiv app installs.

Intet af dette er naturligvis givet på forhånd, forudsætninger skal være opfyldt, og der er både for og imod, men jeg vil mene at Linux vil tabe visse af sine fordele ved ikke at benytte disse fælles libs.

Jeg kan ganske enkelt ikke finde et system, der på en gang både er så hurtigt, sikkert og stabilt som eksempelvis Mint 13. Også andre opfylder udmærket betingelserne, eksempelvis Fedora 17, på trods af aggressive kerne opdateringer, Men uanset dem, så bruger Mint 13 stadig færre ressourser selv med en ældre kernel.

Som dokumentation kan jeg kun vedlægge dette, der viser Mint 13's minimale ressourseforbrug, og fortælle at opstartstiden på en almindelig harddisk er ligeså hurtig som fx Windows 8 på en SSD, ca 15 sek, og på trods af at den er virtuelt installeret med Fusion på OSX, og som sagt på en almindelig harddisk.

Mint 13 er renset for overflødige filer, og den virtuelle hardisk er defragmenteret på Macbook, og OSX er ligeledes renset og vedligeholdt.

Det er vigtigt at nævne, at jeg ikke på noget tidspunkt har oplevet problemer med afhængigheder, som temmelig sikkert er LMDE's specifikke problem med flere repos.

http://db.tt/HvH8jfHd

Mvh

#17: et langsommere systemNu ved jeg ikke hvordan GNOME OS gør det, men statisk linkede programmer eksekverer altså hurtige en dynamisk linkede.

#18

Det er uden tvivl rigtigt, men jeg tror ikke man skal se programhastigheden isoleret, inklusiv opdateringshastigheden.

Jeg mener at huske vi har snakket om det før, hvor jeg oplever fx Backtrack, med tusindvis af installerede programmer, og hvor systemet alligevel er jernhurtigt hvis rengjort,

Det er ikke kun Gnome, men også KDE der samlet fylder mindre på systemet, der hvis der ingen konflikter eller andre problemer er, at systemet samlet set fungerer hurtige des mere slim det er,. Det spiller en rolle om der er uddaterede filer tilstede.

Jeg ved ikke om det kan udtrykkes som en samlet holistisk oplevelse, Er det korrekt, så er det mere vigtigt at systemet er vedligeholdt, end at programmerne har deres egne libs, hvad angår hastigheden.