Gå til innhold

Hvorfor Ikke Vedlegge Avhengigheter?


Anbefalte innlegg

Etter å ha knotet med Linux og installering av programmer i noen år sitter jeg igjen med disse tankene angående avhengigheter som dukker opp når man skal installere en bråte med programmer...

 

Hva med når de som lager programmene også kan legge ved det som kreves av programmet til å installere og kjøre, på den måten slippe unna avhengighetshelvettet. Dette skulle vel ikke være noe problematisk..

 

Scenario: Jeg lager et program som skal gjøre noe. Dette programmet krever en avhengighet for å kunne installeres og kjøres på en linuxboks. Ved min kildekode legger jeg ved denne avhengigheten som blir installert ved siden av programmet selv...

 

Jeg kan godt skjønne at dette ikke er helt ideelt angående enkelte STORE avhengigheter som QT/GTK osv... Men jeg snakker om små avhengigheter/biblioteker...

 

Dette var nå da bare en tanke.. Hvis programmene kunne legge ved biblioteker den trenger så slipper vi stort sett unna avhengighetshelvettet...Skulle jeg vel tro :hmm:

Lenke til kommentar
Videoannonse
Annonse

Så lenge man bruker en oppegående distro med et skikkelig pakkesystem som tar seg av dependencies, er det ikke noe stort problem. Men første gang jeg prøvde linux for endel år siden var det verre.

 

Det er klart at utviklerne av programmer kunne lagt ved libraries, men det blir fort mange libraries og de samme brukes av såpass mange prorammer.

 

Og hvis det er slik at disse library-filene enten skal statisk kompileres eller evt dynamisk linking men at de ligger lokalt til programmet (egen katalog istedenfor /usr/lib osv.) får man problemer når det oppdages en bug eller sikkerhetsfeil i et bibliotek, siden man plutselig må endre det samme biblioteket (evt rekompilere ved statisk linking) for en hel haug med programmer som bruker samme bibliotek. Dette slipper vi elegant unna med dagens løsning.

 

Se f.eks på den nylige jpeg-buggen i windows som krevde oppgradering av en drøss MS-programmer og flere tredjepart-programmer.

Lenke til kommentar

Hovrfor mener du at utviklerene skal gjøre dette? Hva med platformuavhengighet... Skal en legge ved alle mulige libs for alle mulige platformer? Skal en legge ved kildekoden til libs istedet? Skal en binde seg til et spesielt bibliotek om det finnes flere... og hvor langt skal en gå? For å bygge det meste av C baserte ting kreves f.eks. libc, skal alle da legge ved dette?

Eks: jeg lager et bittelite program som beregner noen hasher. Dette gjøres i flere tråder for å effektivisere ting på ett eller anna vis. Da har jeg en applikasjon på kanskje ~300 linjer med C kode. Skal jeg så legge ved kildekoden til pthreads og openssl og kreve at en stakkar skal bygge disse også(i det minste laste dem ned) for å lage min lille applikasjon? Eller om en skal legge ved ferdigkompilerte versjoner så blir det en liten gjeng om jeg vil at applikasjonen skal bygger for GNU/Linux, *BSD, Windows, OSX, Solaris osv ;)

 

Nei, dette hører hjemme på "binærpakkenivå". Kan tildels skjønne om en fikk pakkemaintainerene til å gjøre dette... men er det egentlig ikke dette en har pakkebehandlingssystemer for?

Lenke til kommentar
Hva med når de som lager programmene også kan legge ved det som kreves av programmet til å installere og kjøre, på den måten slippe unna avhengighetshelvettet. Dette skulle vel ikke være noe problematisk..

 

Scenario: Jeg lager et program som skal gjøre noe. Dette programmet krever en avhengighet for å kunne installeres og kjøres på en linuxboks. Ved min kildekode legger jeg ved denne avhengigheten som blir installert ved siden av programmet selv...

Dette du beskriver her er "dll helvete." Et fenomen som oppstod i Windows fordi program x, y og z installerte hver sine dll-filer som samlet seg opp på maskinen. Når man så slettet disse programmene vet man ikke om disse dll-filene er i bruk eller ei, hvis man sletter dem kan man risikere at program a eller b slutter å fungere, og da har du virkelig gjort det.

 

Eventuelt kunne program c installere samme dll som program x, men c installerte en nyere versjon som overskrev den gamle. Desverre var ikke den nye bakoverkompatibel med den gamle, og dermed sluttet program x å fungere. Hva om det blir oppdaget en sikkerhetsfeil i n antall dll-filer? Hvordan får man fikset dette?

 

Det er i det hele tatt mange problematiske scenarioer rundt dette, i GNU/Linux eksisterer ikke disse problemene ettersom det er et pakkesystem som tar seg av alt dette og sørger for at bibliotekfiler og programmer eksisterer i harmoni med hverandre. Så ved mindre man bruker en distro med et dårlig pakkesystem er ikke dette noe problem.

 

Eksempel på binært pakkesystem som gjør jobben sin: Debian sitt apt eller Archlinux sin pacman.

Eksempel på kildekodebasert pakkesystem som gjør jobben sin: Gentoo sin portage eller BSD sin ports.

 

Disse pakkesystemene håndterer alt dette uten problemer (med få eller ingen unntak).

Lenke til kommentar

Når det kommer til argumentet for sikkerhet er jeg enig. Men jeg mente ikke at hvert program som skulle bruke et bibliotek skulle installere sin versjon av den, men heller installere den for alle programmer(hvis ikke en nyere versjon allerede fantes). Grunnen til at jeg tenkte på dette var får å slippe å først få en avhengighetsfeil og dermed søke gjennom nettet for å finne den og installere den(og så hadde den igjen en avhengighet, osv.)..."Forenkling"

 

Edit: Tenker da på RPM,

Endret av DJViking
Lenke til kommentar
Eksempel på binært pakkesystem som gjør jobben sin: Debian sitt apt eller Archlinux sin pacman.

Eksempel på kildekodebasert pakkesystem som gjør jobben sin: Gentoo sin portage eller BSD sin ports.

 

Disse pakkesystemene håndterer alt dette uten problemer (med få eller ingen unntak).

APT systemer er veldig brukervennlig å benytte for installasjon av programmer som krever endel avhengigheter, men jeg er ikke helt så begreistret for slike systemer grunnet sikkerhet.

 

1. Man må kunne stole på at den kilden du nedlaster programmet og alle avhengighetene er til å stole på og at pakkenes integritet ikke er blitt brutt(Spyware,trojan, etc).

2. Hvordan skal man kunne holde orden på hvilken avhengigheter som er blitt installert med referanse til hvilke program som bruker den(for sporbarhet til å avinstallere programmer og avhengigheter som ikke trenges)

Lenke til kommentar
1. Man må kunne stole på at den kilden du nedlaster programmet og alle avhengighetene er til å stole på og at pakkenes integritet ikke er blitt brutt(Spyware,trojan, etc).

2. Hvordan skal man kunne holde orden på hvilken avhengigheter som er blitt installert med referanse til hvilke program som bruker den(for sporbarhet til å avinstallere programmer og avhengigheter som ikke trenges)

Bruk offisielle mirrors. Hvorfor er dette problemet større med et pakkesystem enn å laste ned alle programmene sine fra like mange forskjellige kilder?

 

Fra man pacman:

REMOVE OPTIONS
      -c, --cascade
             Remove all target packages, as well as all packages that  depend
             on one or more target packages.  This operation is recursive.

      -s, --recursive
             For  each  target specified, remove it and all its dependencies,
             provided that (A) they are not required by other  packages;  and
             (B) they were explicitly installed by the user and not pulled in
             as a dependency for other packages.  This option is analagous to
             a backwards --sync operation.

Er det slik funksjonalitet du spør etter?

Lenke til kommentar
1. Man må kunne stole på at den kilden du nedlaster programmet og alle avhengighetene er til å stole på og at pakkenes integritet ikke er blitt brutt(Spyware,trojan, etc).

2. Hvordan skal man kunne holde orden på hvilken avhengigheter som er blitt installert med referanse til hvilke program som bruker den(for sporbarhet til å avinstallere programmer og avhengigheter som ikke trenges)

Bruk offisielle mirrors. Hvorfor er dette problemet større med et pakkesystem enn å laste ned alle programmene sine fra like mange forskjellige kilder?

 

Fra man pacman:

REMOVE OPTIONS
      -c, --cascade
             Remove all target packages, as well as all packages that  depend
             on one or more target packages.  This operation is recursive.

      -s, --recursive
             For  each  target specified, remove it and all its dependencies,
             provided that (A) they are not required by other  packages;  and
             (B) they were explicitly installed by the user and not pulled in
             as a dependency for other packages.  This option is analagous to
             a backwards --sync operation.

Er det slik funksjonalitet du spør etter?

1. Det er vel ikke noe forskjell det. Prøver å unngå å installere programmer som ligger på andre sider enn programmets originale hjemmeside.

2. Hva er pacman? Så grei ut de funksjonene der

Lenke til kommentar

I alle fall Gentoos pakkesystem portage sjekker nedlastede pakker mot en sjekksum, og jeg vil tro andre systemer gjør det samme.

Å fjerne ubrukte pakker finnes også i portage; emerge depclean.

Portage har også en feature for å legge inn dependencies som blir fjernet ved et uhell; revdep-rebuild.

Som sagt, dette er ikke portage-spesifikke features, du finner sikkert lignende i de andre pakkesystemene også.

Lenke til kommentar
Edit: Tenker da på RPM,

"Dependancy hell" kom da rpm fikk sitt inntog med Redhat Linux. Dette fordi rpm er et pakkeformat, ikke et pakkesystem (akkurat som apt bruker dpkg eller .deb pakker). Redhat Linux hadde ikke noe pakksystem, de hadde bare en haug av rpm pakker. Når man da skulle installere masse forskjellige pakker hendte det at man måtte ut på det vide nett og lete etter avhengigheter, som gjerne resulterte i gjentatte nedlastinger av pakker fra kanskje forskjellige nettsider.

 

Mandrake bruker også rpm, men løste dette med å innføre pakkesystem urpmi. SuSE innførte også sitt eget pakkesystem (med yast). Fedora skal vel i hovedsak bruke yum. Om disse pakkesystemene fungerer like bra som det originale apt kan andre svare bedre på enn meg. (Apt er forøvrig portet til både Mandrake, Fedora og SuSE, og da jeg brukte SuSE brukte jeg utelukkende apt uten å få grå hår.)

 

[ Edit: Ser nå at definisjonen av "pakkesystem" kan diskuteres, men med "pakkesystem" mente jeg noe som ikke bare installerer pakker men også håndterer avhengigheter av seg selv. ]

Endret av Cronius
Lenke til kommentar
1. Man må kunne stole på at den kilden du nedlaster programmet og alle avhengighetene er til å stole på og at pakkenes integritet ikke er blitt brutt(Spyware,trojan, etc).

Nå husker jeg ikke alt dette nøyaktig.. Men tror det var noe slikt:

 

Hvis du skal sende inn pakker til Debian, så må du først bli registrert som debian developer.

(IIRC)Det kan man bare bli ved å møte face-to-face en som allerede er developer, og som sjekker ID og slikt, og forsikrer seg at fyren er den han sier at han er.

 

Så, alle pakker som blir sendt inn må signeres digitalt. Når de blir sendt ut til mirrors, blir den signeringen fjernet, en liste over alle pakkene med MD5-sum av hver pakke blir laget, og så signert av Debian.org's offisielle nøkkel. (Husker ikke om det bare var på stable)

 

Så. Hver pakke i apt (med offisielle mirrors) kan spores direkte tilbake til en virkelig person, som folk har møtt i real-life og sjekket identiteten til.

(Det er også deler av grunnen til at når debian.org ble cracket, så kunne ikke angriperene gjøre noe som helst med pakkene.)

 

Så har jeg et lite spørsmål.. Hva får deg til å tro at du kan stole på joe random webside? :p

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...