Lysators nyare filstruktur /pkg

Detta system/denna metod är ej längre aktuellt på Lysators system
Informationen på denna sida kvarstår för att den är eller kan komma att bli av historiskt intresse.

Använda, bygga och installera programvaror i Lysators nya filstruktur

/sw/local är död -- länge leve /pkg

OBS! Om du ens funderar på att installera saker själv i /pkg bör du läsa och förstå detta dokument i sin helhet.

Från och med höstterminen 2002 påbörjades införandet av en radikalt förändrad struktur för hur programvaror hanteras i Lysators datorsystem. Tidigare installerades all programvara som inte följer med operativsystemen i /sw/local med en struktur som beskrivs i Lysator:NWO Denna modell kom tillrätta med en hel del av de problem som fanns med systemet som det såg ut före det. Sedan införandet av /sw/local har det dock uppdagats ett antal brister med det systemet:

• Installerade versioner av programvaror kan råka bli överskrivna med ickefungerande uppgraderingar eller till och med nedgraderingar.
• Även om /sw tillåter installation av komplexa programvarupaket i helt egna kataloger så finns det ingen standard som beskriver hur detta skall ske.
• Det är ofta svårt att avgöra exakt vilken version av ett specifikt programpaket som en viss fil (exv ett delat bibliotek) tillhör.

Konsekvensen av dessa brister är främst att det blir ett vågspel att installera nya programvaror eller uppgradera gamla. Går något sönder kan de enda alternativen för att laga problemet bli att återställa från backup eller kompilera om de gamla paketen - om man nu över huvud taget vet vad som blev förstört.

Man kan förmodligen inte helt bli av med de här problemen, men för att minimera riskerna har vi utgått från följaden kriterier när vi har byggt strukturen för /pkg:

• Till skillnad från /sw där installation av paket i egna kataloger är något man tillämpar då det känns befogat förutsätter /pkg att alla paket installeras i en egen katalog.
• Alla paket installeras på ett sådant sätt att man genom katalognamnet kan sluta sig till vad paketet heter, vilken os/arkitektur det är byggd för samt vilken version av paketet som finns installerat. Ett exempel på ett bibliotek med ett installerat paket är /pkg/gcc/sparc-sol9/3.2.
• När väl ett installerat paket är verifierat att fungera skapas det symboliska länkar för vitala binärer, biblioteksfiler och includefiler i /usr/local.
• /pkg innehåller paket för alla os/arkitekturer samtidigt. På så sätt blir det lättare att se vilka paket som finns på respektive plattform.
• /pkg innehåller även paket för äldre versioner av samma operativsystem vilket gör att uppgradering till en ny version av ett operativsystem inte innebär att burken blir nästan oanvändbar.
• I katalogen /usr/local skall det endast finnas en tom katalogstruktur samt symboliska länkar till paket i /pkg. /usr/local kan utan förvarning komma att raderas och genereras om.
• Vid installation av paket skall man vid länkning av binärer referera till delade bibliotek via /usr/local. Detta är för att undvika långa inkompilerade sökvägar för delade bibliotek som annars kommer att förorsaka långa programladdningstider.

Använda program i /pkg

Att köra program som är installerade i /pkg är inte konstigare än att köra program från /sw/local. Se bara till att /usr/local/bin finns i $PATH så har du tillgång till nästan allt som finns i /pkg. Normalt sköts detta automatiskt när du loggar in på ett system genom läsning av /etc/path.sh som i sin tur använder modules för att hantera PATH, MANPATH, INFOPATH med vänner.

Bygga och installera program för /pkg

OBS! Om du ens funderar på att bygga eller installera egna saker i /pkg så se till att läsa hela stycket.

En liten kul detalj med den nya fina automountern är att man inte längre kan skapa kataloger direkt under /pkg. Man kan dock gå runt det genom att skapa den i /net/pkg-host/export/pkg/pkg från en Solaris-maskin istället.

Till att börja med ser du till att är medlem i gruppen 'pkg'. Det blir du genom att svara på de sex frågorna längst ned på den här websidan. Svarar gör du i ett brev till rootgruppen

Att konfigurera, bygga och installera paket för /pkg från källkodsdistributioner som de vanligtvis brukar se ut idag är inte särskilt svårt. Enklast är att bygga och installera med de scripts som finns för att stödja detta. Följande scripts finns i /pkg/pkgadmin/all/default/bin:

• pkgarch - returnerar namnet på os/arkitektur för anvädning i /pkg
• pkgconfigure (för byggmiljöer som stödjer VPATH) - skapar en underkatalog med namnet som pkgarch returnerar och kör sedan configure med lämpliga flaggor och variabler satta i den katalogen. CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS samt eventuella argument till pkgconfigure skickas till configure
• pkgconfigure_novpath - fungerar som pkgconfigure ovan med skillnaden att konfigurering inte sker i någon underkatalog.
• pkgdefault {pkgnamn} {pkgversion} - skapar den symboliska länken /pkg/$pkgnamn/$pkgarch/default som pekar på /pkg/$pkgnamn/$pkgarch/$pkgversion
• pkgupdate - uppdaterar symlänkfarmen /usr/local med innehåll från /pkg/$pkgnamn/$pkgarch/default och /pkg/$pkgnamn/$pkgarch/$pkgversion

För att t ex bygga paketet "m4" version 1.4 följer man följande recept:

• Se till att andra medlemmar i pkg-gruppen kan ändra de filer du skapar i /pkg. Detta gör du lämpligen genom att köra

  umask 0002

  innan du gör något annat.

• Skapa paketkatalogen med underkatalog för källkod, packa upp källkoden och gå till roten i källkodsträdet:

  mkdir -p /pkg/m4/src
  cd /pkg/m4/src
  tar xfz /tmp/m4-1.4.tar.gz
  cd m4-1.4
  

• Kör 'pkgconfigure'. Följ instruktionerna. Efter avslutad körning kommer du att uppmanas till att gå till byggkatalogen. Följ uppmaningen (vi antar här att vi kör på sparc-sol9).

  pkgconfigure
  cd sparc-sol9
  

• Bygg paketet och kör eventuella testsviter:

  make
  make check || make test
  

• Installera paketet, testa det eventuellt manuellt samt uppdatera symlänkar:

  make install
  pkgdefault m4 1.4
  pkgupdate m4
  

• Städa upp byggträdet:

  make clean
  

Som redan har nämnts är det viktigt att se till att inkompilerade sökvägar för delade bibliotek blir så korta som möjligt. Om möjligt skall endast /usr/local/lib användas förutom de som operativsystemet tillhandahåller. Detta är inte alltid praktiskt möjligt att alltid tillse detta till hundra procent, men det finns visa åtgärder som ger mer utdelning än andra och som alltid skall följas upp:

En hel del paket som tillhandahåller delade bibliotek installerar olika varianter av konfigscript som andra paket sedan kan anropa vid konfiguration för att få fram vad som måste adderas till CPPFLAGS, LDFLAGS och LIBS för att kunna länka med.

Ett exempel är t ex GLib och GTK som använder ATK. ATK består av ett program - pkg-config som läser filer med ändelsen .pc i kataloger som pekas ut av PKG_CONFIG_PATH. Bygger man GLib GTK för /pkg kommer det att installeras ett antal .pc-filer i /pkg/gtk20/sparc-sol9/2.0.6/lib/pkgconfig som vid pkgupdate kommer att symlänkas till /usr/local/lib/pkgconfig. Per default kommer t ex /pkg/gtk20/sparc-sol9/2.0.6/lib/pkgconfig/gtk+-2.0.pc att se ut enligt

prefix=/pkg/gtk20/sparc-sol9/2.0.6
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
target=x11

gtk_binary_version=2.0.0
gtk_host=sparc-sun-solaris2.9

Name: GTK+
Description: GIMP Tool Kit (${target} target)
Version: 2.0.6
Requires: gdk-${target}-2.0 atk
Libs: -L${libdir} -lgtk-${target}-2.0
Cflags: -I${includedir}/gtk-2.0

För att i det här fallet GTK+ skall fungera bra i /pkg-miljön så behöver .pc-filerna modifieras så att prefix och Libs: modifieras till att lyda:

prefix=/usr/local
Libs: -L${libdir} -R${libdir} -lgtk-${target}-2.0

-R anger här sökväg till delade bibliotek utöver det som är standard för systemet. -R är korrekt för Solaris, men på andra plattformar kan syntaxen variera. Läs gärna manualsidan för ld(1) på den plattform du kompilerar. Den generiska metoden för att skicka flaggor till länkaren från gcc (eller de flesta kompilatorer) är att använda "-W"-flaggan. För att länka objektfilen gazonk.o till programmet gazonk som vill länka med libfoo.so som ligger i /usr/local/lib kör man:

• HP-UX:

  gcc -L/usr/local/lib -Wl,+b,: -o gazonk gazonk.o -lfoo

• IRIX, Tru64:

  gcc -L/usr/local/lib -Wl,-rpath,/usr/local/lib -o gazonk gazonk.o -lfoo

Det finns säkert fler varianter på sådana här automatgenererade konfigscript som inte använder ATK, så var vaksamma.

Sex frågor du måste kunna svaret på för att få skriva i /pkg

För att få skrivrättigheter i /pkg svarar du på nedanstående sex frågor. Lämpligen svarar du i form av LysKOMbrev till mötet 'Root (@) Lysator' eller i ett mail till root at lysator dot liu dot se.

Dina skrivrättigheter kommer att gälla i ett år, varpå du får svara på frågorna ytterligare en gång för att återfå dina skrivrättigheter. Det här gör vi för att du inte av misstag ska ha sönder något bara för att du glömt att du hade skrivrättigheter i /pkg.

De sex frågorna:

1. Vilket verktyg använder du för att köra configure för paket som stödjer VPATH?
2. Var någonstans ska binärerna för paketet foo, kompilerat för Solaris 8 på Sparc, hamna efter installation?
3. Vad gör du helst innan du byter ut default-länken?
4. Vad finns det i /usr/local?
5. På vilken katalog ska flaggorna -L och -R peka när du kompilerar?
6. Vilken umask bör du använda när du bygger paket i /pkg?