| Version 4 (modified by , 16 years ago) (diff) |
|---|
Levenscyclus van een pakketje
Hier in het kort de levencyclus van een pakketje:
- Beginnen met nieuw pakketje in je eigen svn tree, mbv newpackage.
- Testen, tunen, aanpassen, recompilen, totdat je denkt dat het pakketje 'goed' is.
- Pakketje comitten in svn.
- Update manager-persoon doet een ./syncupdates, waardoor pakketje op shop.syn3.nl komt.
- Update manager plaatst het pakketje in de update lijst in ontwikkel of test stadium.
- 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 SynService?.
- 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
Hoe een Syn-3 pakketje bouwen?
Hier volgt een stap voor stap handleiding over hoe je een pakketje correct maakt. Volg dit strict en je pakketje zal zeer lang mee kunnen en makkelijk geupdate kunnen worden naar nieuwe versies.
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:
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
- 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
Perl modules zijn zeer eenvoudig en snel te builden. Maak een directory onder source:trunk/npl/perl/ en gooi daar de orginele perl module tarballs in.
Je kan meerdere modules in 1 directory gooien.
Kopieer hierna het voorbeeld script uit source:trunk/npl/perl/buildmods.SlackBuild.example er heen, en ga naar de npl directory:
root@builder:/home/psy/syn3/npl# ./rebuildcheck perl/Audio/buildmods.SlackBuild REBUILD REQUIRED: ./Audio-Mixer-0.7.tar.gz has changed! ... All rebuilds completed.
Je kan het script eventueel weer aanpassen met extra opties of DEPs of NEEDs.
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.
Automatisch dingen laten doen
Moet er iets automatisch geconfigureerd of gestart worden? Kijk dan bij SynAutomation.
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.
