Difference between revisions of "Documentation Team/Obsolete/Services Wrap native packages HOWTO"

From Sugar Labs
Jump to navigation Jump to search
m (link updates)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<noinclude>{{GoogleTrans-en}}{{TOCright}}
+
{{Obsolete | Was only draft content.}}
[[Category:Activity Team]]
+
 
 +
<noinclude>
 +
[[Category:Services/Documentation]]
 
</noinclude>
 
</noinclude>
  
 
== Introduction ==
 
== Introduction ==
  
The purpose of this Guide is describing how to simplify process of usage, by activity developers, packages that are not included to [[0.86/Platform_Components|Sugar Platform]] but well packaged to various GNU/Linux distributions.
+
The purpose of this Guide is to describe how to simplify the usage by activity or service developers of packages that are not included in the [[0.86/Platform_Components|Sugar Platform]] but are well packaged by various GNU/Linux distributions.
 +
 
 +
== Workflows ==
 +
 
 +
* If the service you are planing to use already exists on http://download.sugarlabs.org/services/, just add its name to the ''requires'' field in your [[Documentation Team/Services/Activity Developers Guide|activity]] or [[Documentation Team/Services/Service Developers Guide|service]] ''.info'' file.
 +
* Otherwise, read the rest of this document to learn how to create a service that represents a native package.
  
 
== Detailed description ==
 
== Detailed description ==
  
To use native packages, they should be wrapped into services. Such services are lightweight and contain only proper information about native packages. Also having service wrappers let us collect all distro specific information in one place, because various GNU/Linux distributions could have different names for the same upstream application.
+
To use native packages, they should be wrapped into services. Such services are lightweight and contain only the appropriate information about native packages. By having service wrappers, we can collect all distro-specific information in one place, because various GNU/Linux distributions could have different names for the same upstream application.
  
=== Primal distributions list ===
+
=== Prime distributions list ===
  
In according to http://distrowatch.com/, there are several distributions whose names could be mentioned in service. Followed table is a list of primal distributions from top 100 for 2009 year(excluding source based and special distributions), in most cases theirs names will be the same in all derivate distributions.
+
According to http://distrowatch.com/, there are several distributions whose names could be mentioned in a service. The following table is a list of primary distributions from the top 100 for year 2009 (excluding source-based and special distributions), in most cases, their names will be the same in all derivative distributions.
  
 
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
 
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
Line 25: Line 32:
 
|[http://distrowatch.com/fedora fedora]
 
|[http://distrowatch.com/fedora fedora]
 
|[http://rpm.pbone.net/index.php3/stat/2/simple/2 RPM (yum)]
 
|[http://rpm.pbone.net/index.php3/stat/2/simple/2 RPM (yum)]
|[[Community/Distributions/Fedora|yes]]
+
|[[Fedora|yes]]
 
|-
 
|-
 
|4
 
|4
Line 35: Line 42:
 
|[http://distrowatch.com/debian debian]
 
|[http://distrowatch.com/debian debian]
 
|[http://www.debian.org/distrib/packages#search_packages DEB]
 
|[http://www.debian.org/distrib/packages#search_packages DEB]
|[[Community/Distributions/Debian|yes]]
+
|[[Debian|yes]]
 
|-
 
|-
 
|6
 
|6
 
|[http://distrowatch.com/mandriva mandriva]
 
|[http://distrowatch.com/mandriva mandriva]
|[http://rpm.pbone.net/index.php3/stat/2/simple/2 RPM (urpmi)]
+
|[http://maint.mandriva.com/ RPM (urpmi)]
|[[Community/Distributions/Mandriva|yes]]
+
|[[Mandriva|yes]]
 
|-
 
|-
 
|7
 
|7
Line 48: Line 55:
 
|-
 
|-
 
|10
 
|10
|[http://distrowatch.com/arch arch]
+
|[http://distrowatch.com/arch archlinux]
 
|[http://www.archlinux.org/packages/ Pacman]
 
|[http://www.archlinux.org/packages/ Pacman]
 
|[http://wiki.archlinux.org/index.php/Sugar yes]
 
|[http://wiki.archlinux.org/index.php/Sugar yes]
Line 73: Line 80:
 
|-
 
|-
 
|74
 
|74
|[http://distrowatch.com/altlinux alt]
+
|[http://distrowatch.com/altlinux altlinux]
 
|[http://www.sisyphus.ru:1080/en/packages/ RPM (APT)]
 
|[http://www.sisyphus.ru:1080/en/packages/ RPM (APT)]
|[[Community/Distributions/ALTLinux|yes]]
+
|[[ALT Linux|yes]]
 
|-
 
|-
 
|89
 
|89
Line 99: Line 106:
 
|}
 
|}
  
Package wrappers are regular services, so read [[Documentation_Team/Services/Service_Developers_Guide|Service Developers Guide]] first.
+
Package wrappers are regular services, so read the [[Documentation_Team/Services/Service_Developers_Guide|Service Developers Guide]] first.
  
 
== service.info file ==
 
== service.info file ==
  
In addition to [[Documentation_Team/Services/Service_Developers_Guide#service.info_file|standard]] ''service.info'' file, wrappers' file:
+
In addition to the [[Documentation_Team/Services/Service_Developers_Guide#service.info_file|standard]] ''service.info'' file, the wrappers' file contains the following:
  
 
* ''Service'' section contains only
 
* ''Service'' section contains only
Line 110: Line 117:
 
** description
 
** description
 
** homepage
 
** homepage
* should contain one or more ''Distro:<name>'' sections
+
* It should contain one or more ''Distro:<name>'' sections
* ''Distro:'' section with name ''*'', describes common distro parameters
+
* ''Distro:'' section with name ''*'', describes common distro parameters.
  
Each ''Distro:'' section:
+
Each ''Distro:'' section
  
* should contain ''name'' field which is local package name for service
+
* should contain a ''name'' field which is a local package name for the service,
* optional ''buildtime-name'' field which goes to buildtime.xml feed, by default ''name'' will be used
+
* an optional ''buildtime-name'' field, which goes to the buildtime.xml feed, by default ''name'' will be used.
* for applications, could contain ''main'' field with full path to exec file(could be different for different distributions)
+
* Applications could contain a ''main'' field with a full path to the exec file (which could be different for different distributions).
  
 
== Workflow ==
 
== Workflow ==
  
* create [[#service.info file|service.info]] file
+
* Create a [[#service.info file|service.info]] file.
* add ''Distro:*'' section with common distro parameters
+
* Add a ''Distro:*'' section with common distro parameters.
* add ''Distro:<name>'' sections at least for [[#Primal_distributions_list|sugar supported]] distributions
+
* Add ''Distro:<name>'' sections, at least for [[#Prime_distributions_list|sugar supported]] distributions.
* exec ''0sugar push'' to upload changes to the server
+
* Execute ''0sugar push'' to upload changes to the server.
* if service's application is not well packaged, please consider possibility to [[Documentation_Team/Services/Service_Developers_Guide|add]] source and binary service implementations
+
* If a service's application is not well packaged, please consider the possibility of [[Documentation_Team/Services/Service_Developers_Guide|adding]] source and binary service implementations.
  
== Known issue ==
+
== Known issues ==
  
* in RO mode(check if some package is installed), 0install could work only with deb and rpm based distributions or, if PackageKit is installed, all distributions that current PackageKit version supports
+
* In RO mode (check if some package is installed), 0install can work only with deb and rpm based distributions or, if PackageKit is installed, all distributions that current PackageKit version supports.
* to install packages, system should have PackageKit
+
* To install packages, the system should have PackageKit.

Latest revision as of 14:13, 3 July 2012

Stop hand.png NOTE:
The content of this page is considered
DEPRECATED and OBSOLETE
It is preserved for historical research, along with its talk page.

Was only draft content.


Introduction

The purpose of this Guide is to describe how to simplify the usage by activity or service developers of packages that are not included in the Sugar Platform but are well packaged by various GNU/Linux distributions.

Workflows

  • If the service you are planing to use already exists on http://download.sugarlabs.org/services/, just add its name to the requires field in your activity or service .info file.
  • Otherwise, read the rest of this document to learn how to create a service that represents a native package.

Detailed description

To use native packages, they should be wrapped into services. Such services are lightweight and contain only the appropriate information about native packages. By having service wrappers, we can collect all distro-specific information in one place, because various GNU/Linux distributions could have different names for the same upstream application.

Prime distributions list

According to http://distrowatch.com/, there are several distributions whose names could be mentioned in a service. The following table is a list of primary distributions from the top 100 for year 2009 (excluding source-based and special distributions), in most cases, their names will be the same in all derivative distributions.

Popularity Name in service.info Packages Sugar support
2 fedora RPM (yum) yes
4 suse RPM yes
5 debian DEB yes
6 mandriva RPM (urpmi) yes
7 puppy PET no
10 archlinux Pacman yes
13 slackware TXZ no
38 moblin RPM no
40 frugalware FPM (TAR.BZ2) no
41 pardus PiSi no
74 altlinux RPM (APT) yes
89 turbolinux RPM no
91 crux TAR.GZ no
96 linuxconsole LCM no
99 yoper RPM no

Package wrappers are regular services, so read the Service Developers Guide first.

service.info file

In addition to the standard service.info file, the wrappers' file contains the following:

  • Service section contains only
    • name
    • summary
    • description
    • homepage
  • It should contain one or more Distro:<name> sections
  • Distro: section with name *, describes common distro parameters.

Each Distro: section

  • should contain a name field which is a local package name for the service,
  • an optional buildtime-name field, which goes to the buildtime.xml feed, by default name will be used.
  • Applications could contain a main field with a full path to the exec file (which could be different for different distributions).

Workflow

  • Create a service.info file.
  • Add a Distro:* section with common distro parameters.
  • Add Distro:<name> sections, at least for sugar supported distributions.
  • Execute 0sugar push to upload changes to the server.
  • If a service's application is not well packaged, please consider the possibility of adding source and binary service implementations.

Known issues

  • In RO mode (check if some package is installed), 0install can work only with deb and rpm based distributions or, if PackageKit is installed, all distributions that current PackageKit version supports.
  • To install packages, the system should have PackageKit.