Line 46: |
Line 46: |
| | | |
| == Distribution model == | | == Distribution model == |
| + | |
| + | How Sugar Server might be reused from downstream excluding most obvious way, download its sources. |
| + | |
| + | === Core packages === |
| + | |
| + | Sugar Server is designed to avoid patching its sources in downstream. Reusing upstream binary packages as-is from repositories on http://download.sugarlabs.org is how Sugar Server is being designed. Downstream might create new packages, that don't have file collisions with upstream packages, to have tweaks for local environment. It is being accomplished by: |
| + | |
| + | * sugar-server project has services formed as plugins, from downstream packages such services might be: |
| + | ** enabled/disabled |
| + | ** added new services, e.g., variants of existed services highly tuned for local needs |
| + | * [[The Server/Mace|mace]] tool that processes configuration from sugar-server-base packages is designed to have several configuration sources for the same service, so downstream configuration packages might change/hide/complement upstream configuration |
| + | |
| + | There are three upstream packages: |
| + | |
| + | * sugar-server |
| + | * sugar-server-base |
| + | * mace |
| + | |
| + | These packages might be reused as-is in downstream in most practical, for downstream, way. |
| + | |
| + | === Full cycle solution === |
| + | |
| + | Except just having binary packages, it should be possible to create final OS images on http://packages.sugarlabs.org using only its web UI. The resulted files will be accessible for download from http://download.sugarlabs.org. |
| | | |
| == Distribution == | | == Distribution == |