Changes

Jump to navigation Jump to search
no edit summary
Line 4: Line 4:  
</noinclude>
 
</noinclude>
   −
Service publishing workflow is similar to activities. There is an info file, here ''service/service.info'', which describes current status(not history) of development process. All these fields, finally, go to feed file while publishing new version. Service.info file is an analog of scenario files in regular GNU/Linux distributions like .spec files in RPM.
+
Service publishing workflow is similar to activities. There is an info file, here service/service.info, which describes current status(not history) of development process. All these fields, finally, go to feed file while publishing new version. Service.info file is an analog of scenario files in regular GNU/Linux distributions like .spec files in RPM.
   −
== [Service] section ==
+
== Sections ==
   −
File ''service.info' should contain at least ''[Service]'' section:
+
'''NOTE''' Section names are case sensitive.
   −
* ''name'', the identity of service, this field defines name of feed's root directory on the server http://download.sugarlabs.org/services/ as well
+
=== [DEFAULT] ===
 +
 
 +
This section is required.
 +
 
 +
* ''name'', the identity of the service, this field defines name of feed's root directory on the server http://download.sugarlabs.org/services/ as well
 
* ''summary'', short descriptive line
 
* ''summary'', short descriptive line
 
* ''description'', long descriptive line, to wrap long text, all lines after second, should start with spaces<br>could be omited to reuse ''summary'' field
 
* ''description'', long descriptive line, to wrap long text, all lines after second, should start with spaces<br>could be omited to reuse ''summary'' field
 
* ''license'', in 0install, typically a Trove category, as used on freshmeat.net, but could be [http://fedoraproject.org/wiki/Licensing#Good_Licenses fedora names], since the rest of sugar uses them
 
* ''license'', in 0install, typically a Trove category, as used on freshmeat.net, but could be [http://fedoraproject.org/wiki/Licensing#Good_Licenses fedora names], since the rest of sugar uses them
 
* ''homepage'' web link to project home page
 
* ''homepage'' web link to project home page
 +
* any options that will be global variables see [http://docs.python.org/library/configparser.html#module-ConfigParser]
   −
== [Runtime] section ==
+
=== [Service] ===
    
This section describes parameters that should be taken into account only if service has 0install implementations(including source implementations) in contrast with [[Documentation Team/Services/Native packages usage|pure]] wrappers around native packages.
 
This section describes parameters that should be taken into account only if service has 0install implementations(including source implementations) in contrast with [[Documentation Team/Services/Native packages usage|pure]] wrappers around native packages.
Line 23: Line 28:     
* ''version'', used only for services with [[#Native_versions|native]] versioning scheme
 
* ''version'', used only for services with [[#Native_versions|native]] versioning scheme
 
+
* ''requires'', for any arch and binary implementations, list of runtime services that should exist before using service
 +
requires = <service-name> [<not-before-version>[-<before-version>]] [; ...]
 
* ''binding'', what environment variables, 0install should export to session which uses this service
 
* ''binding'', what environment variables, 0install should export to session which uses this service
 
  binding = [prepend|append|replace] ''<variable-name>'' [''<insert-text-to-prepand-variable-value>''] [; ...]
 
  binding = [prepend|append|replace] ''<variable-name>'' [''<insert-text-to-prepand-variable-value>''] [; ...]
 +
* ''exec'', for applications, shell command which will be executed to start service
 +
* ''include'', files to [[#Include files to bundles|include]] to bundle which will be created for this section
 +
* ''exclude'', files to [[#Include files to bundles|exclude]] from bundle which will be created for this section
 +
* ''arch'', makes sense only for binary services and can contain ''*'' for noarch and ''build'' for binaries
 +
* ''age'' optional [http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning libtool] like age of service
   −
* ''main'', for applications, path to exec file from service root directory
+
=== [Build] ===
   −
* ''requires'', for any arch and binary implementations, list of runtime services that should exist before using service
+
If service contains binary implementations, this section should present to describe building process.
requires = <service-name> [<not-before-version>[-<before-version>]] [; ...]
     −
* exec, command how to make bundle for ''dist'' command, ''0sugar'' will pick up newly created file in service root directory<br>Shell command, executed from service root directory. If this command starts to get complicated, you should move it to a script and just set this attribute to the command to run the script.<br>By default ''0sugar'' just bundle entirely service directory excluding temporary files.
+
Section contains:
   −
exec = make distcheck
+
* ''requires'', what services should be installed before building this one from sources
 
+
requires = <service-name> [<not-before-version>[-<before-version>]] [; ...]
* ''files'', list of files that will be included to runtime bundle and won't be included to buildtime<br>if glob-mask contains symbol ''/'', it will be applied to the whole path string, otherwise only to file names<br>if section exists, only mentioned files will be bundled to runtime tarball, otherwise all files except ''files'' from ''[Buildtime]'' section
+
* ''exec'', command how to build binaries<br>Its value is a shell command, executed inside the build directory $BUILDDIR. It must compile the source in $SRCDIR, putting the final result (ready for distribution) in $DISTDIR. If this command starts to get complicated, you should move it to a script (either inside the main source archive or in a separate dependency) and just set this attribute to the command to run the script.<br>'''NOTE''': This command will be executed not only in service developer environment but also on user side if proper binary wasn't found, so do not use here any development related commands like ''autogen.sh''<br>For example, followed command builds regular autotools based project
 
+
  exec = "$SRCDIR"/configure --prefix="$DISTDIR" CFLAGS="-O2" && make install-strip
  files = <glob-mask> [; <glob-mask> ...]
     −
== [Library] section ==
+
=== [Maintain] ===
   −
Adds additional parameters if service is a library. Libraries should have plain ''version'' value and with ''age'' field, it will be used in [http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning libtool] like style e.g. in [[#Autotools|autotools]] based projects.
+
If service is not a wrap around upstream project i.e. there is no ready to use source tarball, this section will describe how to build source bundle.
    
Section contains:
 
Section contains:
   −
* ''age'' libtool like age of version
+
* ''requires'', dependencies that are need to build source tarball e.g. vala(there is no need in vala compiler after creating source tarball)
 +
* ''exec'', shell command, ''0sugar'' will pick up newly created file in service root directory<br>Shell command, executed from service root directory. If this command starts to get complicated, you should move it to a script and just set this attribute to the command to run the script.<br>By default ''0sugar'' just bundle entirely service directory excluding temporary files.
 +
exec = ./autogen.sh && make distcheck
 +
* ''generate-documentation'', if set, documentation project will be created on [http://api.sugarlabs.org/services/], for now only ''epydoc'' value is supported
   −
== [Buildtime] section ==
+
=== [Packaged] ===
   −
File ''service.info'' could have optional ''[Buildtime]'' section which describes additional parameters that should be taken into account during other service(which uses this one) building i.e. it is an equivalent for *-dev(el) packages in GNU/Linux distributions.
+
This section supplements [Service] if service implementation could be installed from native packaging system.
    
Section contains:
 
Section contains:
   −
* ''requires'', additional dependencies that will be required during building other service which depends on this one
+
* ''<distro-name>'', name in native packaging system
 +
<distro-name> = <alias-for-''name''>
   −
* ''files'', list of files that will be included to buildtime bundle and won't be included to runtime<br>if glob-mask contains symbol ''/'', it will be applied to the whole path string, otherwise only to file names<br>if section exists, only mentioned files will be bundled to buildtime tarball, otherwise all files except ''files'' from ''[Runtime]'' section
+
== Sub services ==
   −
  files = <glob-mask> [; <glob-mask> ...]
+
Service.info could contain several sub services in sections:
 +
  [(Service|Packaged)/<sub-section-name>]
   −
* ''generate-documentation'', if set, documentation project will be created on [http://api.sugarlabs.org/services/], for now only ''epydoc'' value is supported
+
For [Packaged], sub services make sense if there are devel packages in distribution. For [Service], it could be useful to split built installation directory to several bundles e.g. pure binary(which could have several variants for several platforms) and non-arch sub bundles.
   −
== [Build] section ==
+
Sub service sections contain the same options that particular main section contains.
   −
If service contains binary implementations, this section should present to describe building process.
+
To link to sub service, the full name should be used.
   −
Section contains:
+
== Include files to bundles ==
   −
* ''requires'', what services should be installed before building this one from sources
+
* ''files'', list of files that will be included to runtime bundle and won't be included to buildtime<br>if glob-mask contains symbol ''/'', it will be applied to the whole path string, otherwise only to file names<br>if section exists, only mentioned files will be bundled to runtime tarball, otherwise all files except ''files'' from ''[Buildtime]'' section
requires = <service-name> [<not-before-version>[-<before-version>]] [; ...]
     −
* ''exec'', command how to build binaries<br>Its value is a shell command, executed inside the build directory $BUILDDIR. It must compile the source in $SRCDIR, putting the final result (ready for distribution) in $DISTDIR. If this command starts to get complicated, you should move it to a script (either inside the main source archive or in a separate dependency) and just set this attribute to the command to run the script.<br>'''NOTE''': This command will be executed not only in service developer environment but also on user side if proper binary wasn't found, so do not use here any development related commands like ''autogen.sh''<br>For example, followed command builds regular autotools based project
+
files = <glob-mask> [; <glob-mask> ...]
exec = "$SRCDIR"/configure --prefix="$DISTDIR" && make install
 

Navigation menu