Levenscyclus van een pakketje

Hier in het kort de levencyclus van een pakketje:

1. Beginnen met nieuw pakketje in je eigen svn tree, mbv newpackage.
2. Testen, tunen, aanpassen, recompilen, totdat je denkt dat het pakketje 'goed' is.
3. Pakketje comitten in svn.
4. Update manager-persoon doet een ./syncupdates, waardoor pakketje op shop.syn3.nl komt.
5. Update manager plaatst het pakketje in de update lijst in ontwikkel of test stadium.
6. Na een bepaalde test periode komt het pakketje in 'released' stadium.

Het testen bij stap 2 is dus erg belangrijk. Zit er namelijk TOCH nog een fout in je pakketje, dan moeten stappen 3 t/m 5 helemaal opnieuw. Dit kost resources en overhead.

Syn-3 packaging

Om het grootste deel van een pakketje bouwen automatisch voor te bereiden, gebruik je het ./newpackage script. Zie npl/overig/libvmime voor een voorbeeld!

Package manager

Als package manager gebruiken we onder water nog steeds installpkg van Slackware. Feitenlijk is een Syn-3/slackware pakketje gewoon een droge tarbal die uitgepakt word in de root van het te updaten systeem. We gebruiken een wrapper om installpkg heen, om een aantal dingen automatisch af te handellen. Deze wrapper heet syn3-update. source:trunk/npl/syn3/syn3-scripts/scripts/syn3-update

Eigenschappen Syn-3 packaging systeem:

• Pakketjes hebben een zeer basic, makkelijk te begrijpen indeling.
• Geheel geautomatiseerd build systeem dat alle pakketjes altijd in een buildroot bouwt tegen de juiste dependencies. Ieder pakketje heeft een .SlackBuild waarin het 'recept' staat om dit pakketje te bouwen.
• Source tarballs die met het standaard ./configure-systeem werken kunnen meestal helemaal automatisch gebouwd worden, met weinig tot geen aanpasingen aan het buildscript.
• Geen dependency tracking op de servers zelf. (voordeel hiervan is minder administratie)
• Simpelle dependency tracking in het buildsysteem, om build-dependencies in de buildroot te krijgen.
• 1 for all: 1 installatie, die gelijk is bij alle Syn-3 machines. Het is dus niet mogelijk om oudere versies vast te houden: je moet alle pakketjes op je server updaten na de laatste stabiele versie. Hierdoor zijn alle machines exact gelijk en voorkomen verschillende problemen.
• Services kunnen makkelijk toegevoegd worden doordat we daemontools gebruiken. (maak gewoon een nieuw runscript in /service/naam/run) Zie SynServices.
• Automatische start en foutcontrole van post-installatie script in /etc/postinst.d/post.scriptnaam
• Recht-toe-recht-aan update systeem: doordat er geen dependency tracking is, worden alle updates in een vaste volgorde geinstalleerd, voor alle systemen. Voordeel is wederom dat de system gelijk blijven en er minder problemen ontstaan. Iedereen heeft dezelfde problemen en die hoeven we maar 1x op te lossen.
• Vaste plek voor data die gebackuped moet worden: /home/system/
• Updates doen alles automatisch en werken altijd.

Tree indeling

Alle pakketjes staan onder source:trunk/npl. Deze is als volgt ingedeeld:

• system -- Basis systeem packages.
• fileserver -- Onderdelen van de fileserver module
• mailserver -- Onderdelen van de mailserver module
• internetserver -- Onderdlene van de internetserver module
• commonservers -- Server toepassingen die algemeen zijn voor alle syn-3 producten.
• webapps -- Webapplicaties die onder apache draaien: vtiger, mediawiki etc.
• phone -- Onderdelen van de telefoon server. (astersk & co)
• kernel -- Linux kernel en paketten die kernel drivers bevatten. (Beginnen met drv_)
• X -- Grafische toepassing en de X server en libraries
• mediabox -- Packages die interesant zijn voor multimedia boxen. (players, codecs, etc)
• games -- Spelletjes , emulators en andere onzin dingen.
• p2p -- Peer2peer filesharing apps
• perl -- Perl + perl modules. Plaats hier de perlmodules die je nodig bent.
• slackware -- Native slackware packages. Geen nieuwe pakketjes meer aan toevoegen, maar altijd zelf bouwen aub!
• syn3 -- Packages van software en scripts die speciaal voor Syn3 geschreven zijn. Dus SCC, backup, monitoring, splash.
• overig -- Overige packages.
• python -- Python + python modules

Package directory indeling

Een package directory bevat een aantal files, waarvan de .SlackBuild file het belangrijkste is.

Als voorbeeld nemen we trunk/npl/commonservers/openldap, omdat deze bijna alles bevat wat we hebben:

Filename	Hoe?	Omschrijving
openldap.SlackBuild	Verplicht,uniek	Build script van deze package, er mag maar 1 SlackBuild bestaan||
openldap.pkg	Verplicht	Slackware package, moet gecreerd worden door de slackbuild. (tar.gz file)
openldap.arch	Verplicht	Bevat architectuur (meestal i586) Meestal automatisch door SlackBuild
openldap.version	Verplicht	Bevat upstream versie nummer (in dit geval 2.4.11). Meestal automatisch door SlackBuild
openldap.check	Optioneel	Commando voor automatische versie controle. (zie SynVersionCheck?)
openldap.check.ok	Automatisch	Laatst bevestigde output van versie controle.
openldap.major	Optioneel	Zet hier een nummer in dat je ophoogt bij een major update. Alle packages die hier tegen gecompiled zijn zullen dan opnieuw gecompiled worden. Gebriuk hiervoor het rebuildcheckall commando.
openldap.md5	Automatisch	MD5 sum van alle files in directory NA de laatste build. Gebruikt/gemaakt door rebuildcheck commando.
openldap.depver	Automatisch	Major versies van dependencies waartegen deze package gecompiled is. Gebruikt/gemaakt door rebuildcheck commando.
libldap.pkg	Optioneel	Een SlackBuild kan meerdere pakketjes genereren. Iedere .pkg is dus een appart pakketje die je kunt remoteinstallen of in het update systeem kunt trappen.
libldap.arch	Verplicht	Iedere .pkg MOET een bijbehorende .arch hebben
libldap.version	Verplicht	Iedere .pkg MOET een bijbehorende .arch hebben
openldap_dev.arch	Optioneel	Development headers en librarys komen in apparte _dev package, ivm resource besparing. (dit scheelt vaak 80% ruimte)
openldap_dev.pkg	Verplicht
openldap_dev.version	Verplicht

De rest van de files worden allemaal gebruikt door de slackbuild file en hebben dus geen speciale naamgeving of verplichtingen:

openldap-2.4.11.tgz	Dit is de upstream sourcecode van openldap. Ieder pakketje zal meestal een degelijke file hebben
post.openldap	Installatie script dat na het installeren word uitgevoert. Zie SynAutomation
openldap-master.backup	Backup scripts voor Syn-3 backup systeem. Zie SynBackup
openldap-master.restore
openldap-slave.backup
openldap-slave.restore
start	Service start stop scripts, zie SynServices
stop
openxchange.schema	Ldap specifieke zooi
samba.schema
slapd.conf.master
slapd.conf.mirror1
slapd.conf.mirror2
debuglevels
ldap.conf
minimum.ldif

Hoe een Syn-3 pakketje bouwen?

Een syn-3 pakketje bouw je met het newpackage commando in de npl directory.

Dit zal het grootste deel autmomatisch voorbereiden en doen.

Kijk hier voor een stap voor stap voorbeeld van een wat lastiger pakketje.

Build logboek

Begin gelijk met een buildlogboek op deze wiki. Hier zet je in waar je files weghaalt, wat je gedaan, waarom je bepaalde dingen doet, welke problemen je tegenkomt, wat voor patches etc. Een buildlog hoeft niet supernetjes te zijn. Het is een logboek, dus als achteraf blijkt dat iets anders gemoeten had, dan wijzig je dat niet, maar tik je gewoon verder. (Zo word het dus een verhaal) Gebruik npl/games/openmsx als voorbeeld.

Hier zie je een overzicht van alle reeds aanwezige build logs:

• npl/X/libglew
• npl/commonservers/postgresql
• npl/fileserver/cups
• npl/games/openmsx
• npl/mediabox/libsdl-image
• npl/mediabox/xbmc
• npl/overig/libical
• npl/overig/libvmime
• npl/overig/pv
• npl/perl/Mail_IMAPClient
• npl/perl/Parse_RecDescent
• npl/perl/version
• npl/toolchains

Zoek het juiste sources en patches bijelkaar

Het is belangrijk dat je altijd de orginele source-tarball download en de daarbij behorende patches. Wil je een CVS of SVN versie bouwen? Maak dan van de CVS of SVN versie die je gebruikt een tarball met een juiste naam.

• Source tarball: pakket_naam-1.2.3.tar.gz
• CVS tarball: pakketje_naam-12.04.2007.tar.gz
• SVN tarball: pakketje_naam-3452.tar.gz

Zorg dat je de patches er los bij zet. Dus geen pre-patched tarball, want dit is lastig met latere updates!

Gebruik indien mogelijk altijd de laatste stable versie.

Een goede plek voor patches zijn de debian en gentoo repository's.

Kies een lokatie en pakketnaam

De pakketnaam mag alleen letters, cijfers en underscores bevatten. Dus foomatic_db in plaats van foomatic-db!!!'''

Bepaal met de lijst hier bovenaan in welke directory het pakketje thuis hoort. Maak hieronder een directory aan met de naam van het pakket.

Je mag ook een subdirectory aanmaken om meerdere packages te groeperen. Zoals source:trunk/npl/overig/alsa.

Kopieer de tarball en patches hierin.

File lokaties

• Configfiles in /etc/ en /home/system worden normaal gesproken gewoon overschreven net als alle andere files. Wil je dit niet, geef dan de config file een naam die eindigd op .new. Het systeem overschrijft dan bestaande files niet. Het etc-update programma dat automatisch word uitgevoerd na een install, zorgt ervoor dat de files gerenamed of verwijderd worden indien nodig.
• De standaard prefix voor binary packages is /usr.
• Webapplicaties, die rechstreeks onder apache moeten draaien zet in /var/www/htdocs/syn3/naam. Om de applicatie automatisch in de webportal weer te geven moeten er minimaal 2 bestanden in deze directory staan:
  • webportal.desc Deze bevat de naam, als pure tekst.
  • webportal.png Deze bevat het logo.

Gebruik de standaard .SlackBuild als basis

Als je wijzigingen maakt in het slackbuild script, vergeet dan niet om achter alle belangrijke regels een exit 1 toe te voegen:

commando bla bla bla || exit 1

Kopieer het voorbeeld bestand source:trunk/npl/packagename.SlackBuild.example naar packagename.SlackBuild. Het pakketje zal automatisch deze naam krijgen.

root@builder:/p/npl/fileserver/foomatic_db# cp ../../packagename.SlackBuild.example foomatic_db.SlackBuild
root@builder:/p/npl/fileserver/foomatic_db# ls -l
total 15720
-rw-r--r--  1 root root 16091293 2007-06-30 09:22 foomatic-db-3.0-20070630.tar.gz
-rwxr-xr-x  1 root root     1943 2007-08-23 16:33 foomatic_db.SlackBuild*

Nu ben je al klaar om een eerste testbuild te doen. We starten het rebuildcheck commando vanuit de npl directory:

root@builder:/p/npl/fileserver/foomatic_db# cd ../..
root@builder:/p/npl# ./rebuildcheck foomatic_db
REBUILD REQUIRED: ./foomatic-db-3.0-20070630.tar.gz has changed!
REBUILDING /p/npl/fileserver/foomatic_db/foomatic_db.SlackBuild:
Buildroot up-to-date check: ............................................................................................................DONE
Buildroot /p/builder/buildroot0 repareren/syncen...OK
/p/npl/fileserver/foomatic_db word gekopieerd naar werkdirectory /p/builder/buildroot0/tmp/build
*** Chroot naar /p/builder/buildroot0 en starten van foomatic_db.SlackBuild in /tmp/build:
/home/vservers/builder/dev/pts/0: No such file or directory
1 /tmp/build > basename ./foomatic_db.SlackBuild
...
3 /tmp/build > DST=/tmp/pkg
5 /tmp/build > '[' /tmp/pkg ']'
17 /tmp/build > cd foomatic-db-3.0-20070630
/bin/syn3_build_automake: line 17: cd: foomatic-db-3.0-20070630: No such file or directory
17 /tmp/build > exit 1
57 /tmp/build > exit 1
*** Er ging iets mis tijdens het bakken in de buildroot!
Error while rebuilding /p/npl/fileserver/foomatic_db/foomatic_db.SlackBuild!

We zien in kleur stap-voor-stap wat er er gebeurd. Blijkbaar kan een directory niet gevonden worden. Laten we even in de buildroot duiken om te kijken watsgebeurd:

root@builder:/p/npl# chroot ../builder/buildroot0/
stderr is not a tty - where are you?
[Syn-3] root@darkstar.example.net /# cd /tmp/build/
[Syn-3] root@darkstar.example.net /tmp/build# ls
foomatic-db-20070630/  foomatic-db-3.0-20070630.tar.gz  foomatic_db.SlackBuild*

De directory in de tarball is anders dan de tarball naam zelf, vandaar dat het mis gaat. Dit lossen we op door SRC_DIR=... in het buildscript aan te passen naar foomatic-db-20070630. Hierna proberen we het nog eens te builden:

root@builder:/p/npl# ./rebuildcheck foomatic_db
...
37 /tmp/build/foomatic-db-20070630 > exit 0
60 /tmp/build > syn3_strip /tmp/pkg
63 /tmp/build > syn3_move_dev /tmp/pkg /tmp/pkgdev
64 /tmp/build > syn3_makepkg /tmp/pkgdev foomatic_db_dev 20070630 i586
Not creating empty pacakge
67 /tmp/build > syn3_makepkg /tmp/pkg foomatic_db 20070630 i586
tar-1.13: foomatic_db.pkg.tar is the archive; not dumped
*** Build gelukt.
* Packages terugmoven naar originele directory..
/p/builder/buildroot0/tmp/build/foomatic_db.arch ...
/p/builder/buildroot0/tmp/build/foomatic_db.version ...
/p/builder/buildroot0/tmp/build/foomatic_db.pkg ...

* Klaar ja!
Updating md5 for /p/npl/fileserver/foomatic_db/foomatic_db.SlackBuild...
Updating dependency information for /p/npl/fileserver/foomatic_db/foomatic_db.SlackBuild...
All rebuilds completed.

Woohooooooo het is gelukt! Je ziet nu de volgende files:

root@builder:/p/npl# ls fileserver/foomatic_db -l
total 30740
-rw-r--r--  1 root root 16091293 2007-06-30 09:22 foomatic-db-3.0-20070630.tar.gz
-rwxr-xr-x  1 root root     1925 2007-08-23 17:14 foomatic_db.SlackBuild*
-rw-r--r--  1 root root        5 2007-08-23 17:15 foomatic_db.arch
-rw-r--r--  1 root root      179 2007-08-23 17:15 foomatic_db.md5
-rw-r--r--  1 root root 15364391 2007-08-23 17:14 foomatic_db.pkg
-rw-r--r--  1 root root        9 2007-08-23 17:15 foomatic_db.version

• De .pkg is de 'droge slackware tarball', maar dan met een .pkg extentie.
• De .arch bevat de architectuur. (meestal i386)
• De .version bevat de versie. In dit geval 20070630.
• De .md5 bevat md5sums, zodat het systeem kan zien dat het pakketje gewijzigd is en dus opnieuw gebuild moet worden.

Kijk in de .pkg om te kijken of de files en directorys op de goede plekken staan:

root@builder:/p/npl# tar -tzvf fileserver/foomatic_db/foomatic_db.pkg 
drwxr-xr-x root/root         0 2007-08-23 17:14:58 ./
drwxr-xr-x root/root         0 2007-08-23 17:14:43 usr/
drwxr-xr-x root/root         0 2007-08-23 17:14:43 usr/share/
drwxr-xr-x root/root         0 2007-08-23 17:14:43 usr/share/foomatic/
drwxr-xr-x root/root         0 2007-08-23 17:14:43 usr/share/foomatic/db/
-rw-r--r-- root/root     16156 2007-08-23 17:14:43 usr/share/foomatic/db/oldprinterids
drwxr-xr-x root/root         0 2007-08-23 17:14:43 usr/share/foomatic/db/source/
drwxr-sr-x /                 0 2007-06-30 09:22:45 usr/share/foomatic/db/source/PPD/
drwxr-sr-x /                 0 2007-08-23 17:14:45 usr/share/foomatic/db/source/PPD/Brother/
-rw-r--r-- /              7166 2007-06-30 09:22:04 usr/share/foomatic/db/source/PPD/Brother/BRHL32_3_GPL.ppd.gz
... (heel veel files)

Als dit goed lijkt is het pakketje eigenlijk al klaar!

Kijk bij SynBuild hoe je het pakketje toevoegd aan de svn tree.

Verderop staat uitgelegd HOE je het pakketje makkelijk op je Syn-3 server krijgt om te testen.

Build dependencies

Soms heeft een pakketje andere paketten nodig om gebuild te kunnen worden. Deze geef je in het buildscript aan, er staan al wat voorbeelden in het standaard voorbeeld script:

• #NEED:packagename -- packagename word in de buildroot geinstalleerd, voordat de build begint.
• #DEP:packagename -- packagename word eerst gerebuild-checked, en daarna in de buildroot geinstalleerd.

Gebruik DEP voor paketten die exact moeten kloppen en altijd gerebuild moeten zijn. Bijvoorbeeld als je een kernel module bouwt tegen de kernel source.

Extra configure en make opties

Bij de juiste regels in het standaard buildscript kun je extra opties aangeven. Bijvoorbeeld:

export CONFIGURE_OPTS="--uber-pimp-modus=yes --beer=/dev/psy"
export MAKE_OPTS="-j1"
export NOTEST=1
syn3_build_automake $SRC_DIR /tmp/pkg || exit 1

In dit geval word het testen overgeslagen. De -j1 gebruik je om problemen bij parallel builds op te lossen. (op systemen waar j standaard hoger dan 1 is)

Meer info over syn3_build_automake vind je in source:/trunk/npl/syn3/syn3_build/src/syn3_build_automake

Soms is syn3_build_automake helemaal niet in staat om een pakketje te bouwen. (bijvoorbeeld als men geen automake-compatible sourcetar ball heeft). In dit geval is het het handigste om deze regel weg te halen en de handmatige build commando's er neer te zetten. Zorg er in elk geval voor dat het pakketje geinstalleerd word in /tmp/pkg, zodat de rest van het buildscript het pakketje correct in kan pakken.

Bijzondere pakketten

Kernel modules

Iedere kernel module heeft wel weer zn eigen eigenaardig heden, vandaar dat we dit niet stap voor stap uitleggen.

De package naam dient in elk geval met drv_ te beginnen. Kijk in source:trunk/npl/kernel bij de bestaande drv_pakketjes voor wat voorbeelden.

Perl modules

Deze bouw je met het newpackage commando.

Je kan meerdere modules in 1 directory gooien, waardoor er automatisch voor iedere module een .pkg gemaakt word.

Python modules

Deze bouw je met het newpackage commando:

psy /home/psy/syn3/npl # ./newpackage python python_pysqlite http://oss.itsystementwicklung.de/download/pysqlite/2.5/2.5.0/pysqlite-2.5.0a.tar.gz
Using python/python_example.SlackBuild as slackbuild..
...

PHP pear modules

Zie PearandPHP

Grafische programmas voor X

Bij grafische programma voor X ben je vaak erg veel dependencies nodig en is het vaak nodig om /etc/xorg_build.conf in je script te 'sourcen'.

Het is verstandig om eerst even naar bestaande X buildscripts te kijken en hier 1 van als voorbeeld te pakken.

Services aan firewall toevoegen

Als je een pakketjes maakt die op een poort luistert, moet je deze ook aan de services-lijst van de firewall toevoegen.

Zo kan de beheerder de nieuwe service lekker makkelijk toevoegen aan zn firewall.

Kijk in SynFirewall hoe dat moet.

Automatisch dingen laten doen

Moet er iets automatisch geconfigureerd of gestart worden? Kijk dan bij SynAutomation.

Automatische upstream versie controle

Het is mogelijk om automatisch te laten controleren of er een nieuwe versie beschikbaar is van de source code van een pakketje. Zie SynVersionCheck?.

Testen en vrijgeven van het pakketje

Hier staat de juiste volgorde beschreven hoe je het pakketje test en released.

Installatie op een bestaande server

Deze methode is erg handig in de eerste testfase van een pakketje:

Om een pakketje naar een Syn-3 server te 'pushen' gebruik je de remoteinstall tool:

root@builder:/home/psy/syn3/npl# ./remoteinstall tar 192.168.0.1 rebuild
* Build check:
* Package tar zoeken:/home/psy/syn3/npl/.tmp/D/tar-1.16.1-i586-3023.tgz
* install:
Checking ssh key on 192.168.0.1...OK
192.168.0.1: Uploading and installing
192.168.0.1: Running installpkg /tmp/tar-1.16.1-i586-3023.tgz
192.168.0.1: Installing package tar-1.16.1-i586-3023...
192.168.0.1: PACKAGE DESCRIPTION:
192.168.0.1: Executing install script for tar-1.16.1-i586-3023...
192.168.0.1:
192.168.0.1: Running etc-update...
192.168.0.1: Running ldconfig...DONE
192.168.0.1: Syncing changes to disk...DONE
192.168.0.1: Postinstall check...
192.168.0.1: Installed /tmp/tar-1.16.1-i586-3023.tgz.
192.168.0.1: Install on 192.168.0.1 OK
All installs done

Deze tool doet autmatisch een rebuild check, installeerd automatisch een sshkey, en installeerd daarna het pakketje.

Werkt je pakketje niet? Maak dan de juiste wijzigingen aan de slackbuild en run dit commando nog een keer. Supersnel en handig.

Je kan het pakketje zelfs naar parallel naar meerdere servers pushen. Tik ./remoteinstall zonder parameters voor meer info.

Opnemen in het update systeem

Als het pakketje lijkt te werken is het tijd om het pakketje beschikbaar te maken voor meerdere mensen. Alleen de uber-gasten kunnen dit.

Uploaden

Gebruik de syncupdate tool om het pakketje naar de centrale Syn-3 update server te uploaden:

root@builder:/home/psy/syn3/npl# sh syncupdates.sh tar
Checking ssh key on updates@banaan.datux.nl...OK
At revision 3428.
Verifying update ./overig/archivetools/tar/tar.pkg...Skipping, already uploaded

Updatemanager

Hierna ga je naar de update manager in de shop ​http://www.syn-3.nl/mosaddphp/regserver_2/regserver/listupdates.php en vul je de gegevens van de update eventueel alvast in. Vooral developers notities zijn handig.

Ook is het belangrijk om eventueel een vereiste optie in te vullen, zodat alleen users met de juiste licentie de update krijgen. Zie SynRegserver.

Een update gaat door 4 stadia:

• Development: het pakketje is nog in ontwikkeling en moet alleen gebruikt worden om te prutsen. Het pakketje mag uberkrikky zijn.
• Testing: het pakketje is klaar om getest te worden door andere mensen: het is vrij zeker dat er geen dataverlies of corruptie optreed door de update. Er kunnen natuurlijk wel andere dingen mis gaan.
• Accepted: het pakketje is getest en goed bevonden. Vanaf nu kan er niks meer veranderd worden. De update is nog niet beschikbaar voor het grote publiek.
• Released: het pakketje is beschikbaar voor het grote publiek. Syn-3 servers zullen hun administrator informeren via het monitoring systeem.

Kijk dus uit met het zetten van het released statium!

Naast deze stadia kunnen we ook Syn-3 versies aangeven in de update manager. Aan de hand van deze versie kun je vervolgens weer een installatie CD maken.

Basis systeem pakketjes die minimaal nodig zijn om een server te installaren zet je in source:trunk/bootcd/base.list

Zie SynProducts voor meer info.

Zorgen dat het pakketje op de install CD komt

Zodra een pakketje in de shop staat kan er een Syn-3 release versie nummer aangehangen worden. Hierna is het mogelijk om een install cd te maken en automatisch te laten testen.

Zie SynInstaller en SynTest.