Open SYN-3 versie 5

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

Algemeen

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

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.