| Xaraya | C.P. Dudley |
| Request for Comments: 0051 | Xaraya Development Group |
| Category: Standards Track | January 2004 |
RFC-0051: Xaraya Package Distribution System
This document specifies an Xaraya standards track protocol for the Xaraya community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Xaraya Official Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Digital Development Foundation (2004). All Rights Reserved.
This RFC describes the mechanism used to distribute Xaraya and its modules and themes. There will be a concept of distribution packages, which will include the core and several other selected modules/themes. But individual modules/themes will also be available for download on their own. This document will describe the process used to make that system possible.
Xaraya is made up of the following components:
There are two ways of distributing those components:
Both ways are desirable for different reasons. This document will tackle each one in turn.
This is a selection of modules and or themes included with the core package as a single download and installable entity. It is to be expected that there would be one installation routine that would be specific to this package and would setup and configure everything included in the package. An example of this would be the community configuration. That would be a seperate download and would include all modules necessary for that scenario. The configuration file for the installer would also be present so the installation routine would handle everything thats necessary for this specific setup.
This would mean that each .conf.php file in html/modules/installer/xarconfigurations would correspond to a distribution package. They would all be in the core repository but those that dont apply to the package being built would not be included in the packaging process.
So community.conf.php would be included in the community distribution package, along with all modules and themes applicable to that package, but intranet.conf.php and ecommerce.conf.php would not.
The configuration file would be read and handled during installation in a similar fashion to the way it is handled today, however the default would be for it to just install what is specified. Only if the user selects "Custom" will they be able to choose which modules, roles etc get installed as specified by the configuration file. It should be possible to specify some choices as compulsory and others as optional. The user would then be able customise their install based on the optional choices - but only if they selected a "custom install". Since only one configuration file would be included in each package there is no need for the configuration selection screen during the install - one that had an option of "custom" or not would replace it.
A package would be produced through use of the build system in the core repository. "bk build <packagename>" would seem a sensible way to have it work. This would then pull in modules from the modules repository and themes from the themes repository as necessary.
The resultant .tar.gz and .zip files would be named after the configuration file and version of core xaraya used (e.g. community-0.9.7.tar.gz) and then be put up for download on xaraya.com and/or sourceforge.net. Ideally automatically at the end of the build script.
As well as distribution packages there is also a need to have individual modules and themes available for download seperately. So someone could install the core package and then install the specific modules and themes they require. This also enables someone to download an extra module and add it to any existing installation.
The build system would need adding to the modules repository so that one could run commands such as "bk build <modname>". This would then produce a .tar.gz and a .zip file for that specific module. These would be automatically copied to the appropriate download area - whether xaraya.com or sf.net. Ideally the file should be named with the appropriate version number extracted from xarversion.php.
For situations where module A requires module B, module dependancies would be used. These should also include versioning if possible, so module A requires version 2.1 or higher of module B. They would still both be individual downloads and would need downloading seperately.
The above holds true for themes as well as modules.
Language packs could be handled in a similar fashion. They do not currently have any form of versioning however, so maybe that might be something worth introducing.
A possible downloads directory structure for xaraya.com could be:
html/downloads/packages/core-0.9.7.tar.gz
core-0.9.7.zip
community-0.9.7.tar.gz
community-0.9.7.zip
modules/articles-1.2.tar.gz
articles-1.2.zip
xarbb-2.5.tar.gz
xarbb-2.5.zip
themes/fancy_theme-1.2.tar.gz
fancy_theme-1.2.zip
languages/en_GB.utf-8-1.1.tar.gz
en_GB.iso8859-1-1.1.zip
Each directory could contain an index.php file which loaded a prettier looking directory index in a style that matched the look and feel of xaraya.com. It could also load in information about the module/item in question from the registered extensions entries in the database.
0.1 - Initial Draft
The DDF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the DDF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC-0.
The DDF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the DDF Board of Directors.
Funding for the RFC Editor function is provided by the DDF