This page is still a draft. It will be translated to english as soon as things get clearer

Deze pagina bevat de planning voor de VOLGENDE grote update van SYN-3, versie 5.0. Voorlopig zullen eindgebruikers nog versie 4.x gebruiken.

sources: http://open.syn3.nl/syn3/trac/default/browser/branches/5.x

Open SYN-3 versie 5

De planning voor de volgende major update van SYN-3.

Versie 5.x zal echt open source worden: alleen de webinterface (SCC) is closed en commercieel. De rest is open en krijgt een GPL achtige licentie, en is dus perfect te installeren en gebruiken zonder SCC. De SCC is als losse package te installeren en moet ook geregistreerd worden via de bekende procedure.

4.x blijft door ontwikkeld worden in de interne tree. 5.0 word parallel hieraan ontwikkel in de nieuwe open tree. We proberen 5.0 de meeste prioriteit te geven. In 4.x bouwen we alleen nog dingen die echt noodzakelijk zijn om te het verkopen of in de lucht te houden. Nieuwe grote features schuiven we door naar 5.1.

Onderzochte build systemen

Debian

Dingen zoals pbuilder etc, blijven te lastig en omslachtig in gebruik. Bovendien te debian specifiek.

Fedora

​http://koji.fedoraproject.org/koji/buildtargets , dit is een omgeving die packages build voor fedora. De daadwerkelijke packages moeten wederom met lastige spec-files gemaakt worden: ​https://fedoraproject.org/wiki/How_to_create_an_RPM_package.

met mock kunnen buildroots gemaakt worden, maar er is nog steeds redelijk wat configuratie nodig. Het is makkelijker om dan gewoon yum+rpm te bruiken om een buildroot te maken. (yum --installroot werkt goed)

Opensuse

Men heeft ​http://en.opensuse.org/Build_Service. Dit maakt het mogelijk om packages op een buildfarm te laten compilen voor verschillende architecturen en distro's. Hiervoor is het echter nog steeds nodig om met een lastige Spec-file te werken. Als een package multi-distro moet zijn is het nodig om nog meer obscure macros in deze specfile te plaatsen.

De tijd die het kost om iets te builden is tegenwoordig meestal niet het probleem. De gebruikvriendelijkheid waarmee je kan builden en waarmee je vooral fouten tijdens de build kan debuggen is vele malen belangrijker. Met buildservice gebeurd alles remote en kun je dus niet makkelijk chrooten naar je buildroot om dingen te onderzoeken en testen.

Ubuntu

Ubuntu heeft launchpad.net: Dit is bedoeld om software projecten te hosten en heeft niks te maken met packaging.

rpath

rpath, rbuilder en canory zien er interesant uit, en doen al voor een deel wat we willen: builden, makkelijk nieuwe packages creeeren, versie beheer, branching en het maken van een appliance of install cd.

Te uitgebreid en generiek. Focussed zich teveel op appliances, en te weinig op het buildprocess zelf. Build 'scripts' zijn gemaakt in python: als een build mis gaat kun je niet makkelijk chrooten en onderzoeken. Men gaat er voor het gemak van uit dat een buildscript in 1x werkt, terwijl dit in de praktijk juist het lastigste deel is.

Als je een php module wilt maken, bevelen ze zelfs aan om ergens van een vage community site een voorbeeld php-recipe te pakken! dit hoort er standaard in te zitten vind ik. (net als python en perl modules)

Zeer hoge leer curve: python buildscript met specifieke functies en classes, nieuwe onbekende package manager, veel verschillende tools, speciale dev-environment nodig die je moet downloaden, online account nodig op rpath.org.

De conary package manager zou wel gebruikt kunnen worden: conary kan binary packages (rpm/deb) 'wrappen'. Bovendien kan er een wrapper-build-recipe geschreven worden die onze native buildscripten aanroept. conary is gemaakt door 1 van de oorspronkelijke ontwerpers van rpm. ​http://wiki.rpath.com/wiki/Conary

crux/arch

Een soort slackware on steroids. Mooi concept, maar de package manager is te simpel voor ons. (standaard geen goede support voor dependencies etc.)

Globale planning

1. Nieuwe buildomgeving + build systeem + package manager (edwin)
2. Alle pakketjes migreren van oude naar nieuw buildsysteem. Opsplitsen in losse pakketjes voor configuratie (_conf pakketjes). Filepaden aanpassen voor FHS. (iedereen)
3. "de rest" (iedereen)
4. migratie pad bedenken voor 4.x naar 5.0.

Algemeen

• We proberen in 5.0 alleen grote arcituur wijzigingen door te voeren: Grote wijzigingen die achteraf lastig zijn om te maken. Kleine wijzigingen die later kunnen horen niet bij 5.0, maar in een volgende release thuis! (denk hierbij aan nieuwe features voor de SCC of versie updates van packages)
• 5.0 word geforked van een bestaande distro + package manager: welke word nog onderzocht.
• Het buildsysteem is inmiddels zo flexibel opgezet dat er gemakkelijk van verschillende distros geforkt kan worden. (debian werkt al)
• Meer volgens standaarden werken. /home/system moet weg: alle dingen volgens FHS opslaan.
• Backup systeem moet hele systeem backuppen en niet alleen /home/system.
• Resource besparing: Zorgen dat het ontwikkelen en releasen van updates sneller en makkelijker gaat. Dit kan door bijvoorbeeld ruimte- en bandbreedte besparing.
• Alle development behalve de SCC en regserver gaat plaats vindne in een open tree.
• Open SYN-3 is te installeren zonder SCC, zodat 3rd party's het ook kunnen gebruiken en voorzien van eigen software.
• Updaten en installeren van software kan via een package manager op de commandline, zonder dat je daarvoor licenties of SCC nodig bent.
• SYN-3 installatie CD's zijn zelf te builden. De installer is ook open. (is het nu ook al omdat het shell scripts zijn met dialog)
• Het moet makkelijk zijn om meerdere versies te onderhouden. Voorbeeld: 5.1 (stable) en 5.2. (test). Het moet eenvoudig mogelijk te zijn een pakketje te bouwen voor alleen 5.1 of 5.2. Hoe doen we dit? svn branches? of een andere manier?

build tree

• Logischer indeling: nu zijn er directorys zoals npl/mailserver en npl/overig . Dit moet logischer. Misschien is het een goed idee om de directorys overeen te laten komen met de 'opties': Dus de paketten voor een fileserver (F optie) komen in een F directory?
• Overal staan handige scripts verspreid. Dit geeft nogal verwarring. Bovendien hebben alle scripts een lelijke commandline interface. Al deze scripts in 1 directory gooien die je in je path kunt zetten. alle scripts beginnen met syn3-... .
• Ondersteuning voor meerdere architecturen. Het liefst willen we niet een apparte tree per architectuur, want dit betekend dubbel werk. Misschien kunnen we de buildscripts zo aanpassen, dat je kan aangeven welke architectuur gebuild moet worden? Zo hou je 1 buildscript en 1 versie, voor alle architecturen.
• Gebuilde packages NIET in de svn tree opslaan? Nu doen we dit wel. Dit kost veel resources en is onhandig met committen en updaten. Is het niet handiger om de gegenereerde packages buiten de svn op te slaan? Dit kunnen we dan ook gelijk kopellen aan het nieuwe package systeem. Dus je build een package, en het resultaat word meteen in je lokale package repository gezet. Deze repository kun je weer 'syncen' met de online development-repository. Als het pakketje goed werkt, kan hij naar de test-repository en vervolgens naar de stable-repository gecopieerd.
• Alle slackware packages die nu nog over zijn vervangen door eigen gebuilde packages.

Build systeem

Naam: IBO - In-Build-Out

• Input en output van het buildsysteem buiten de tree brengen. Input zijn source tar balls en patches. Output zijn gegenereerde packages voor verschillende architecturen en syn3 versies. Hierdoor blijft de SVN tree vele malen kleiner en is het maken van branches en doen van commits vele malen sneller.
• .SlackBuild renamen naar .build.
• Standaard build-script uitbreiden zodat hij standaard de subdirectory 'root' in de package kopieerd. Dit is veel makkelijker met uitbreiden en wijzigen.
• Configuratie en runscripts in apparte packages. Dus mysql_conf en apache_conf. Er worden heel vaak dingen aan de configuratie gewijzigd, waardoor nu het hele pakket opnieuw gebuild moet. (zonde van de tijd en resources)
• Ondersteuning voor meerdere architecturen, terwijl we toch 1 build-script per package houden.
• Handige buildtemplates maken, waarmee je met 1 commando een nieuw pakketje kan bouwen: Templates voor: automake, perl-, php-, python-modules, debian-source packages.

Het systeem word zo opgezet dat je met meerdere build trees kan werken. 3rd party developers kunnen hun eigen tree opzetten met eigen shizzle. Je hoeft niet persee svn te gebruiken, zolang de indeling van de tree maar volgens de standaard stuctuur is. Voor het gemak noemen we alle trees die de 'standaard build indeling' hebben .._build. De build-scripts staan op een andere plek, en deze plek kan je in je PATH zetten. build-scripts zijn dus losgekoppeld build-tree's. Dit is logischer.

We hebben de volgende svn trees:

​https://open.syn-3.nl/syn3/svndav/default/trunk/scripts/	alle build tools en scripts. Deze zet je in je lekker handig in je PATH.
​https://open.syn-3.nl/syn3/svndav/default/trunk/syn3_build/	alle opensyn3 packages staan hier in, volgens de standaard indeling.
​https://(intern)/trunk/datux_build/	alle datux closed source packages. op dit moment alleen de SCC en regserver

De scripts staan op dit moment in dezelfde tree als syn3_build, maar deze kunnen ook ergens anders staan.

|- (naam)_build
   |- (version)                        hier word het onderscheid tussen verschillende syn3 versie gemaakt. (branches komen hier dus)
      |- pkg                           hieronder staan de daadwerkelijke packages . (DEZE DIR + SUBDIRS KOMT IN SVN)
      |  |- (packagename)              package build directory van 1 pakketje.
      |     |- build                   buildscript van de package. (bevat ook extra info, zie verderop)
      |     |- buildstatus             hierin bewaard het buildsysteem allerlei informatie om automatsich dingen te kunnen doen. Dit is de enige file die door het build-systeem aangepast word.
      |     |- in                      hier zet je input files in die je nodig bent, zoals patches en sources. Dingen die met #DOWNLOAD in de build staan worden hier ook naartoe gedownload. 
      |     |- out                     dit is de main package: alles wat hieronder staat komt in (packagename).deb.
      |     |  |-control               dingen zoals dependencys en install-scripts komen hier in.
      |     |    |- preinst            pre/post install scripts
      |     |    |- postinst
      |     |    |- prerm
      |     |    |- postrm
      |     |    |- version            Optioneel: Versie van het pakketje. Het buildsysteem voegt automatsich het buildnummer toe aan het versie nummer, of bedenkt het versie nummer helemaal zelf.
      |     |    |- depends            Dependencys: 1 packagename per regel gevolgd door een deb-control style versie indicatie. (zie man deb-control)
      |     |    |- pre-depends        
      |     |- out.(subname)           dit is een subpackage. Een subname 'out.dev' resulteert in een package '(packagename).dev'. 
      |        |- (zelfde indeling als main)
      |- templates                     Hier staan templates die gebruikt worden door syncreate. Hiermee is het makkelijk mogelijk nieuwe buildscripts te maken.
      |- cache                         Hierin komen tijdelijke files en gebuilde packages. Deze directory kun je in principe leeghalen, als je alle buildresults geupload hebt.
         |- downloads                  Dingen die je download met #DOWNLOAD komen hier, om herhaaldelijk downloaden te voorkomen.
         |- ...                        Diverse andere directorys, waaronder de tree met gebuilde packages.

Build scripts

Het buildscript is een normaal shellscript, dat verantwoordelijk is voor het compilen van code. de resultaten moet in een pkg/.. subdirectory gezet worden. (de 'make install').

Het script word echter door het buildsysteem geparsed. Het buildsysteem herkent de volgenden commentaren:

• #DEP:(packagename) Het pakketje heeft deze package nodig om te compilen. als het dep-pakketje een hoger major-nummer heeft dan de vorige keer, dan is er een rebuild nodig van het huidige pakketje.
• #NEED:(packagename) Het pakketje heeft deze package nodig in de buildroot, maar bij een major-wijziging is er geen recompile noodzakelijk.
• #DOWNLOAD:(urls) [(sourcefilename)] Het pakketje heeft deze sourcefiles nodig. Het systeem cached de gedownloade files in downloads. Het systeem kan ook op onze eigen mirror kijken, indien de orginele url niet meer beschikbaar is. (er komen handige scripts om deze mirror te voorzien van sources). Het systeem onthoud md5sums van de sources in de buildstatus file. Deze MOETEN altijd het zelfde zijn. (ivm corruptie van files of gehackte download servers). De url is opioneel: indien niet gegeven, kijkt het systeem alleen lokaal en in onze mirrors. (bij veel oude pakketjes zijn de urls onbekend)
• #SRC:(source-path) Het pakketje heeft deze lokale files nodig. Deze files hoeven juist niet altijd dezelfde inhoud te hebben, zoals bij DOWNLOAD wel moet. Indien de inhoud van een source-path veranderd, zal het systeem het pakketje rebuilden.

Rebuilden

Het rebuilden gaat intelligent. De resultaten van een build worden in buildstatus opgeslagen. Hierdoor kan het systeem bepalen wat er bij een rebuild moet gebeuren:

• Als het buildscript aangepast is word deze uitgevoerd in een buildroot.
• Als alleen het control gedeelte van een pkg veranderd is, word gekeken of het vorige pakketje (met zelfde md5sum) nog op in de dist directory staat. in dat geval word alleen het control deel in het pakketje geupdate. dit gaat niet werken zo: het control deel kan ook aangepast worden door het buildscript zoals het nu ingedeeld is. iedere package zal een apparte 'content' en 'meta' subdir moeten krijgen met ieders hun eigen buildscript als we dit netjes willen implementeren
• ...

Package management

• Het huidige systeem vervangen door een goede package manager. Het nieuwe buildsysteem heeft meerdere package backends: dit maakt het testen en onderzoeken makkelijker.
• Dependency tracking.
• Meerdere repositorys voor meerdere versies (dus bijvoorbeeld dev/test/stable, maar ook 5.0/5.1/5.2 . Misschien dev/test/stable symlinken naar een bepaalde versie ofzo?)
• Meerdere architecturen. Te beginnen met i686 en x86_64. Mogelijkheid open houden voor andere architecturen in de toekomst.

Init systeem

• Alle slackware zooi op /etc/rc.d moet weg.
• Houden we deamontools of is er iets handigers dat het zelfde kan + meer. (upstart) Ik denk dat vervangen eerst een TE grote stap is. Dit kunnen we eventueel nog in de volgende release doen. Als we alle startup-scripts van alle pacakges al in losse conf packages hebben zal dit ook geen probleem zijn.
• Netwerk en firewall: Dit moeten scripts worden die standaard de SCC aanroepen, maar die eenvoudig vervangen of uitgebreid kunnen worden door handmatige configuratie door de user. (iptables , ifconfig commands)