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.

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.

De build-trees zijn als volgt ingedeeld:

(naam)_build/sources/(packagename)/(source files)	hier komen gedownloade source.tar.gz files, patches en directorys te staan. deze staan appart, zodat branchen makkelijker/kleiner is. grote sources kun je eventueel niet comitten. (xbmc is bijvoorbeeld 600 mb) In de build-scripts
(naam)_build/(version)/buildroot.list	lijst van packages die in de buildroot moeten om packages voor deze versie te bouwen
(naam)_build/(version)/build/(packagename)/(packagefiles)	het daadwerkelijke buildscript + configfiles. Een package heeft ook een speciale indeling, zie verderop.
(naam)_build/(version)/dist/(dev|test|stable)/(architecture)/(packagefilename)	de door build gegenereerde packages. De dist tree is 1 op 1 compatible met de package manager en word dus met een online repository gesynced. Deze tree word niet in svn gecommit om resources en tijd te besparen. Het buildscript haalt hier de dependencys ook uit. (en anders online als hij ze hier niet kan vinden). Zooi die net gebuild is komt in dev te staan. dit is een lastig deel en is me nog niet helemaal duidelijk hoe we het gaan worden. wat gebeurd er als 2 mensen het zelfe pakketje rebuilden? kunnen ze hem beide upload en elkaars pakketje overschrijven? of krijgen de pakketjes een unieke naam van de developer in zich? apparte dev per developer kan ook nog. hoe worden depencendys in buildroots geinstalled? met dpkg -i, of met apt-get vanuit de buildroot zelf?

Een package directory is als volgt ingedeeld:

(packagename)/build	het buildscript, aangeroepen in een buildroot als de package opnieuw gecompiled moet. Deze bevat ook nog extra informatie, zoals versie nummers en build dependencys en major nummers, zie verder op.
(packagename)/buildresults	hierin bewaard het buildsysteem allerlei informatie om automatsich dingen te kunnen doen: Build-nummer bijhouden, major-versie nummers van builddependencys waartegen gebouwd is. md5sums.

INPUT files die een pakketje krijgt als hij in de builddir gebuild word:

(packagename)/sources/

automatisch aangemaakt door buildsysteem: bevat de sources uit de bijbehorende hoofd-sources directory.

OUTPUT files dat een pakketje moet bevatten OF geneneren via het build-script

(packagename)/dist/(packagename)/(directorystructuur)	Hierin staan de files daadwerkelijk gecompilede files die in het pakketje moeten komen. Deze worden hier meestal in gezet via "make install"-methode, maar er kunnen van te voren ook al een aantal files aanwezig zijn. (bijvoorbeeld config files)
(packagename)/dist/(packagename)/info	algemene informatie, zoals runtime dependencys en een aantal velden zoals je bij debian control files ziet.
(packagename)/dist/(packagename)/preinst	Dit zijn de pre- en post- install script voor het installeren en verwijderen van packages. (naamgeving is a la debian)
(packagename)/dist/(packagename)/postinst	Al deze files hoeven niet altijd aanwezig te zijn: vaak kunnen ze automatisch 'bedacht' worden door het build systeem.
(packagename)/dist/(packagename)/prerm
(packagename)/dist/(packagename)/postrm
(packagename)/dist/(sub-packagename)/...	Het is mogelijk dat een build-script meerdere pakketjes genereerd. Bijvoorbeeld een ..._tools pakketje voor losse tools, of ..._dev pakketje voor development headers. Deze directory heeft dezelfde indeling als de packagename directory. Verplichte files die hier missen, worden overgenomen van de hoofdpackage.

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)