6.3. Pakkehåndtering

Pakkehåndtering er et ofte etterspurt tillegg til LFS boken. En pakkebehandler gjør det mulig å spore installasjonen av filer, noe som gjør det enkelt å fjerne og oppgradere pakker. I tillegg til binære filer og bibliotekfiler, vil en pakkebehandler håndtere installasjonen av konfigurasjonsfiler. Før du begynner å lure, NEI - denne delen vil ikke snakke om eller anbefale noen spesiell pakkebehandler. Det det gir er en sammenstilling av de mer populære teknikkene og hvordan de fungerer. Den perfekte pakkebehandleren for deg kan være blant disse teknikkene, eller være en kombinasjon av to eller flere av disse teknikkene. Denne delen omtaler kort problemer som kan oppstå når du oppgraderer pakker.

Noen grunner til at ingen pakkebehandlere er nevnt i LFS eller BLFS inkluderer:

  • Å håndtere pakkehåndtering tar fokuset bort fra målene i disse bøkene - lære hvordan et Linux-system er bygget.
  • Det er flere løsninger for pakkehåndtering, som hver har sine styrker og ulemper. Det er vanskelig å inkludere en som tilfredsstiller alle målgrupper.

Det er noen hint skrevet om emnet pakkehåndtering. Besøk Hints prosjektet og se om en av dem passer ditt behov.

6.3.1. Oppgraderingsproblemer

En Package Manager gjør det enkelt å oppgradere til nyere versjoner når de slippes. Vanligvis kan instruksjonene i LFS og BLFS Book brukes til å oppgradere til de nyere versjonene. Her er noen punkter du bør være klar over når du oppgraderer pakker, spesielt på et kjørende system.

  • Hvis Glibc må oppgraderes til en nyere versjon, (f.eks. Fra glibc-2.19 til glibc-2.20), er det tryggere å gjenoppbygge LFS. Selv om du kanskje kan bygge om alle pakkene i avhengighetsrekkefølge, anbefaler vi ikke det.
  • Hvis en pakke som inneholder et delt bibliotek blir oppdatert, og hvis navnet på biblioteket endres, må alle pakkene som er dynamisk koblet til biblioteket, bli kompilert på nytt for å koble til det nyere biblioteket. (Legg merke til at det ikke er noen sammenheng mellom pakkeversjonen og navnet på biblioteket.) Ta for eksempel en pakke foo-1.2.3 som installerer et delt bibliotek med navnet libfoo.so.1. Si at du oppgraderer pakken til en nyere versjon foo-1.2.4 som installerer et delt bibliotek med navnet libfoo.so.2. I dette tilfellet må alle pakker som er dynamisk koblet til libfoo.so.1, bli kompilert på nytt for å koble mot libfoo.so.2. Merk at du ikke bør fjerne de forrige bibliotekene før de avhengige pakkene er kompilert på nytt.

6.3.2. Teknikker for pakkehåndtering

Følgende er noen vanlige pakkehåndteringsteknikker. Før du tar en beslutning om en pakkebehandler, bør du undersøke de forskjellige teknikkene, spesielt ulempene med den spesielle ordningen.

6.3.2.1. Alt er i hodet mitt!

Ja, dette er en pakkehåndteringsteknikk. Noen mennesker finner ikke behovet for en pakkehåndterer fordi de kjenner pakkene intimt og vet hvilke filer som er installert av hver pakke. Noen brukere trenger heller ikke pakkehåndtering fordi de planlegger å gjenoppbygge hele systemet når en pakke endres.

6.3.2.2. Installer i separate kataloger

Dette er en forenklet pakkehåndtering som ikke trenger noen ekstra pakke for å administrere installasjonene. Hver pakke er installert i en egen katalog. For eksempel er pakke foo-1.1 installert i /usr/pkg/foo-1.1 og en symlink er laget fra /usr/pkg/foo til /usr/pkg/foo-1.1. Når du installerer en ny versjon foo-1.2, installeres den i /usr/pkg/foo-1.2 og den forrige symlenken erstattes av en symlink til den nye versjonen.

Miljøvariabler som PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH og CPPFLAGS må utvides til å omfatte /usr/pkg/foo. For mer enn noen få pakker blir denne ordningen uhåndterbar.

Dette er en variant av den forrige pakkehåndteringsteknikken. Hver pakke er installert på samme måte som forrige skjema. Men i stedet for å lage symlink, blir hver fil symlinket til /usr hierarkiet. Dette fjerner behovet for å utvide miljøvariablene. Selv om symlinkene kan opprettes av brukeren for å automatisere opprettelsen, er det blitt skrevet mange pakkeforvaltere ved bruk av denne tilnærmingen. Noen få av de populære inkluderer Stow, Epkg, Graft og Depot.

Installasjonen må forfalskes, slik at pakken tror at den er installert i /usr, men i virkeligheten er den installert i /usr/pkg hierarkiet. Å installere på denne måten er vanligvis ikke en triviell oppgave. Tenk for eksempel på at du installerer en pakke libfoo-1.1. Følgende instruksjoner installerer ikke pakken ordentlig:

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

Installasjonen vil fungere, men de avhengige pakkene lenker kanskje ikke til libfoo som du forventer. Hvis du sammenstiller en pakke som lenker mot libfoo, kan du legge merke til at den er koblet til /usr/pkg/libfoo/1.1/lib/libfoo.so.1 i stedet for /usr/lib/libfoo.so.1 som du forventer . Den riktige tilnærmingen er å bruke DESTDIR-strategien for å falske installasjonen av pakken. Denne tilnærmingen fungerer som følger:

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install

De fleste pakker støtter denne tilnærmingen, men det er noen som ikke gjør det. For pakker som ikke er kompatible, kan det hende du må installere pakken manuelt, eller du kan finne ut at det er lettere å installere noen problematiske pakker i /opt.

6.3.2.4. Tidsstempel basert

I denne teknikken blir en fil tidsstemplet før installasjonen av pakken. Etter installasjonen kan en enkel bruk av finnkommandoen med de aktuelle alternativene generere en logg over alle filene som er installert etter at tidsstempelfilen ble opprettet. En pakkesjef skrevet med denne tilnærmingen er install-log.

Selv om denne ordningen har fordelen av å være enkel, har den to ulemper. Hvis filene blir installert med en annen tidsstempel enn gjeldende klokkeslett under installasjonen, blir de ikke sporet av pakkehåndtereren. Denne ordningen kan også bare brukes når en pakke er installert om gangen. Loggene er ikke pålitelige hvis to pakker blir installert på to forskjellige konsoller.

6.3.2.5. Sporing av installasjonsskript

I denne tilnærmingen blir kommandoene som installasjonsskriptene utfører registrert. Det er to teknikker som man kan bruke:

LD_PRELOAD-miljøvariabelen kan settes til å peke på et bibliotek som skal lastes inn før installasjon. Under installasjonen sporer dette biblioteket pakkene som blir installert ved å knytte seg til forskjellige kjørbare filer som cp, installere, mv og spore systemanropene som endrer filsystemet. For at denne tilnærmingen skal fungere, må alle kjørbare filer kobles dynamisk uten suid eller sgid bit. Forlasting av biblioteket kan forårsake noen uønskede bivirkninger under installasjonen. Derfor anbefales det at man utfører noen tester for å sikre at pakkebehandleren ikke bryter noe og logger alle passende filer.

Den andre teknikken er å bruke strace, som logger alle systemanrop som ble utført under utførelsen av installasjonsskriptene.

6.3.2.6. Opprette pakkearkiv

I dette skjemaet blir pakkeinstallasjonen forfalsket til et eget tre som beskrevet i Symlink pakkeadministrasjonen. Etter installasjonen opprettes et pakkearkiv ved hjelp av de installerte filene. Dette arkivet brukes deretter til å installere pakken enten på den lokale maskinen eller kan til og med brukes til å installere pakken på andre maskiner.

Denne tilnærmingen brukes av de fleste av pakkeforvalterne som finnes i kommersielle distribusjoner. Eksempler på pakkeforvaltere som følger denne tilnærmingen er RPM (som for øvrig kreves av Linux Standard Base-spesifikasjonen), pkg-utils, Debian's apt og Gentoos Portage-system. Et hint som beskriver hvordan man tar i bruk denne stilen for pakkeadministrasjon for LFS-systemer, finner du på http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt.

Oppretting av pakkefiler som inkluderer avhengighetsinformasjon er kompleks og er utenfor LFS omfanget.

Slackware bruker et tar basert system for pakkearkiver. Dette systemet håndterer ikke målrettet pakkeavhengighet slik mer komplekse pakkeforvaltere gjør. For detaljer om pakkehåndtering av Slackware, se http://www.slackbook.org/html/package-management.html.

6.3.2.7. Brukerbasert styring

Denne ordningen, unik for LFS, ble utviklet av Matthias Benkmann, og er tilgjengelig fra Hints Prosjektet. I denne ordningen blir hver pakke installert som en egen bruker på standardplasseringene. Filer som tilhører en pakke identifiseres enkelt ved å sjekke bruker-IDen. Funksjonene og manglene ved denne tilnærmingen er for kompliserte til å beskrive i dette avsnittet. For detaljer, se antydningen på http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.

6.3.3. Distribusjon av LFS på flere systemer

En av fordelene med et LFS system er at det ikke er noen filer som avhenger av plasseringen av filer på et disksystem. Kloning av et LFS bygg til en annen datamaskin med samme arkitektur som basesystemet er så enkelt som å bruke tar på LFS partisjonen som inneholder rotkatalogen (ca. 250MB ukomprimert for et basis LFS bygg), kopiere den filen via nettverksoverføring eller CD- ROM til det nye systemet og utvide det. Fra det tidspunktet vil noen få konfigurasjonsfiler måtte endres. Konfigurasjonsfiler som kanskje må oppdateres inkluderer: /etc/hosts,/etc/fstab, /etc/passwd, /etc/group, /etc/shadow, /etc/ld.so.conf, /etc/sysconfig/rc .site, /etc/sysconfig /network og /etc/sysconfig/ifconfig.eth0.

Det kan hende at det må bygges en tilpasset kjerne for det nye systemet, avhengig av forskjeller i systemmaskinvare og den opprinnelige kjernekonfigurasjonen.

Det har vært noen rapporter om problemer når du kopierte mellom lignende, men ikke identiske arkitekturer. For eksempel er instruksjonssettet for et Intel-system ikke identisk med en AMD-prosessor, og senere versjoner av noen prosessorer kan ha instruksjoner som ikke er tilgjengelige i tidligere versjoner.

Endelig må det nye systemet startes via Seksjon 8.4, "Bruke GRUB til å sette opp startprosessen".

Forrige Hjem Neste