Open SYN-3 versie 5

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

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)

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 en 1 handige interface maken. zoiets als: syn3-build, syn3-remoteinstall. Alle interne hulpscript een andere naam of directory geven.
• 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

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

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