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

Open SYN-3 versie 5

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

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.

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)
• 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?

SVN 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

• 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
   \- downloads                        dit is de cache voor automatisch gedownloade sources. alleen lastig te verkrijgen sources worden gecommit. (of verdwijnende )
      \- apt                           dit is de cache voor apt-get dingen, word gebruikt om een buildroot op te bouwen. niks hiervan word gecommit.
   \- (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.
      |     \- SRC                     deze directory bestaat standaard niet, maar word automatisch gevuld met de #SRC: dingen die in build staan.
      |     \- DOWNLOAD                deze directory bestaat standaard niet, maar word automatisch gevuld met de #DOWNLOAD: dingen die in build staan.
      |     \- 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)
      \- dist                          gebuilde packages komen hier te staan. 
         \- (architecture)
            \- (packagename).deb       een gebuilde package voor een bepaalde arcitectuur. kan via scripts geupload worden naar de test-repository.

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.
• ...

Package management

• Het huidige systeem vervangen door een goede package manager. Ik zit te denken aan aptitude. (dpkg).
• 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)