Visa källa för Lysators nyare filstruktur /pkg

{{inaktivt}}


[[Kategori:Instruktioner]]
== Använda, bygga och installera programvaror i Lysators nya filstruktur ==

=== <tt>/sw/local</tt> är död -- länge leve <tt>/pkg</tt> ===

'''OBS! Om du ens funderar på att installera saker själv i <tt>/pkg</tt> 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 <tt>/sw/local</tt> med en struktur som beskrivs i [http://www.lysator.liu.se/local/datorhandbok/nwo.html 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
<tt>/sw/local</tt> 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 <tt>/sw</tt> 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 <tt>/pkg</tt>:
* Till skillnad från <tt>/sw</tt> där installation av paket i egna kataloger är något man tillämpar då det känns befogat förutsätter <tt>/pkg</tt> 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 <tt>/pkg/gcc/sparc-sol9/3.2</tt>.
* 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 <tt>/usr/local</tt>.
* <tt>/pkg</tt> 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.
* <tt>/pkg</tt> 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 <tt>/usr/local</tt> skall det <i>endast</i> finnas en tom katalogstruktur samt symboliska länkar till paket i <tt>/pkg</tt>. <tt>/usr/local</tt> 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 <tt>/usr/local</tt>. 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 <tt>/pkg</tt> ==

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

== Bygga och installera program för <tt>/pkg</tt> ==

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

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 <tt>/net/pkg-host/export/pkg/pkg</tt> 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 <tt>/pkg</tt> 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:

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

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

<ul>
<li>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
<pre>umask 0002</pre>
innan du gör något annat.

<li>Skapa paketkatalogen med underkatalog för källkod, packa upp
källkoden och gå till roten i källkodsträdet:
<pre>
mkdir -p /pkg/m4/src
cd /pkg/m4/src
tar xfz /tmp/m4-1.4.tar.gz
cd m4-1.4
</pre>
</li>

<li>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).
<pre>
pkgconfigure
cd sparc-sol9
</pre>
</li>

<li>Bygg paketet och kör eventuella testsviter:
<pre>
make
make check || make test
</pre>
</li>

<li>Installera paketet, testa det eventuellt manuellt samt uppdatera symlänkar:
<pre>
make install
pkgdefault m4 1.4
pkgupdate m4
</pre>
</li>

<li>Städa upp byggträdet:
<pre>
make clean
</pre>
</li>

</ul>

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 <tt>/usr/local/lib</tt> 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
<tt>CPPFLAGS, LDFLAGS och LIBS</tt> 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 - <tt>pkg-config</tt> som läser filer med ändelsen
<tt>.pc</tt> i kataloger som pekas ut av <tt>PKG_CONFIG_PATH</tt>.
Bygger man GLib GTK för <tt>/pkg</tt> kommer det att installeras ett
antal .pc-filer i <tt>/pkg/gtk20/sparc-sol9/2.0.6/lib/pkgconfig</tt>
som vid <tt>pkgupdate</tt> kommer att symlänkas till
<tt>/usr/local/lib/pkgconfig</tt>. Per default kommer t ex
<tt>/pkg/gtk20/sparc-sol9/2.0.6/lib/pkgconfig/gtk+-2.0.pc</tt> att se
ut enligt

<pre>
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
</pre>

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

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

<tt>-R</tt> anger här sökväg till delade bibliotek utöver det som är
standard för systemet. <tt>-R</tt> ä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 <tt>gazonk</tt> som vill länka med <tt>libfoo.so</tt> som
ligger i <tt>/usr/local/lib</tt> kör man:

<ul>

<li> HP-UX:
<pre>gcc -L/usr/local/lib -Wl,+b,: -o gazonk gazonk.o -lfoo</pre>
</li>

<li> IRIX, Tru64:
<pre>gcc -L/usr/local/lib -Wl,-rpath,/usr/local/lib -o gazonk gazonk.o -lfoo</pre>
</li>

</ul>

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