Difference between revisions of "Platform Team/Guide/Sweets Packaging"
| Line 41: | Line 41: | ||
* ''init'', get feed file from the server and place it to dist/ | * ''init'', get feed file from the server and place it to dist/ | ||
* ''fetch'', rsync entirely dist/ from the server | * ''fetch'', rsync entirely dist/ from the server | ||
| − | * ''dist'', | + | * ''dist'', create source or any arch tarball in ''dist/'' directory and tweak ''dist/feed.xml'' correspondingly |
| − | * '' | + | * ''dist-bin'', create binary tarball for current arch in ''dist/'' directory and tweak ''dist/feed.xml'' correspondingly |
* ''push'', rsync dist/ to the server | * ''push'', rsync dist/ to the server | ||
* ''lint'', check feed file on the server | * ''lint'', check feed file on the server | ||
The regular work flow after increasing version/stability in ''service.info'' file, is invoking one of ''dist*'' command to change local feed in ''dist/'' and place there tarballs, then invoke ''push'' command to rsync changed files to the server. | The regular work flow after increasing version/stability in ''service.info'' file, is invoking one of ''dist*'' command to change local feed in ''dist/'' and place there tarballs, then invoke ''push'' command to rsync changed files to the server. | ||
Revision as of 14:18, 19 December 2009
Introduction
The purpose of this HOWTO is describe how to get benefits of Sugar Services for your library/application, simplify support fork flows and let your users(developers) use your code in simple and convenient way.
Services are just a set of definitions for urls and names for 0install feeds, it provides to activity developers convenient way to use services. But regular 0install work flow still works. The rest of document describes sugar specific work flow to meet 0sugar benefits.
service.info file
Service publishing work flow 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.
All fields should be placed to [Service] section
- name, the identity of service, this field defines name of feed's root directory on the server http://download.sugarlabs.org/services/ as well
- summary, short descriptive line
- description, long descriptive line, to wrap long text, all lines after second, should start with spaces
- homepage
- version, current version
- stability, level of stability for version, see [1]
- license, in 0install, typically a Trove category, as used on freshmeat.net, but could be fedora names, since the rest of sugar uses them
- binding, what environment variables, 0sugar should export to session which uses this service
binding = [prepend|append|replace] <variable-name> [<insert-text-to-prepand-variable-value>] [; ...]
- main, for applications, path to binary from service root directory
- gpg-key, identify gpg key to sign feeds, useful if there are several keys to sign
0sugar-publish tool
To start using services, install 0sugar-publish which is main tool to maintain services infrastructure.
0alias 0sugar-publish http://download.sugarlabs.org/services/0sugar-publish/feed.xml
While working, 0sugar-publish creates dist/ directory in project's root and uses it as a rsynced copy of service's directory on the server. So, you need ssh access to sunjammer server, create ticket for shell.sugarlabs.org category on http://bugs.sugarlabs.org/.
0sugar-publish commands are:
- init, get feed file from the server and place it to dist/
- fetch, rsync entirely dist/ from the server
- dist, create source or any arch tarball in dist/ directory and tweak dist/feed.xml correspondingly
- dist-bin, create binary tarball for current arch in dist/ directory and tweak dist/feed.xml correspondingly
- push, rsync dist/ to the server
- lint, check feed file on the server
The regular work flow after increasing version/stability in service.info file, is invoking one of dist* command to change local feed in dist/ and place there tarballs, then invoke push command to rsync changed files to the server.