Difference between revisions of "Activity Team/Obsolete/Native Packages"

From Sugar Labs
Jump to navigation Jump to search
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<noinclude>
+
{{Obsolete | It was only draft content}}
  {{TOCright}}
+
 
  [[Category:Zero Sugar]]
+
<noinclude>{{TOCright}}
 +
[[Category:Zero Sugar]]
 
</noinclude>
 
</noinclude>
 +
== Summary ==
  
== GNU/Linux distributions ==
+
The GNU/Linux distributions integration feature of Zero Sugar is not intended to follow all the requirements of native packages and cannot be reused for distribution of official repositories, i.e., Zero Sugar is '''NOT''' a meta-packaging tool.
 
 
GNU/Linux distributions integration is not intended to follow all requirements for native packages and in most cases cannot be reused for distribution official repositories. There are only three major ideas behind distribution support:
 
* run Zero package in particular GNU/Linux distribution using native packaging system
 
* do not interfere with official packages
 
* make packages reusable for 0install deployment model
 
  
Zero Sugar is designed to support primarily [http://build.opensuse.org/ OBS] workflow. Each OBS package is an all-sufficient Zero Sugar entity (with one exception, it knows nothing about 0install infrastructure) i.e. it could be used as meta packaging tool (at least within [http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets distributions] that OBS supports). It is possible to follow regular OBS procedures for these Zero packages e.g. creating links to Zero packages and branching them within OBS.
+
There are only three major ideas behind native distribution support:
 +
* make packages, built on [http://build.opensuse.org/ OBS], reusable for the 0install deployment model;
 +
* as a side effect, Zero packages could be installed on GNU/Linux distributions that OBS supports, also, Zero packages might be reused for OBS-based Sugar distributions;
 +
* Zero Sugar does not support most of the 'devil-in-details' packaging features that make distro people's life so funny.
  
Each Zero package consist of:
+
Each OBS package is generated by the {{Code|0sugar}} tool, and might be built on a bunch of rpm/deb-based distributions within OBS. It is possible to follow regular OBS procedures for Zero packages, e.g., creating links and branching them.
* ''<package-name>.info'' Zero Sugar spec file
 
* ''<package-name>.changes'' regular OBS changes file
 
* ''revision'' file with revision number of current version
 
* ''<package-name>.spec'' stub spec file for rpm based distributions
 
* stub spec files for deb based distributions
 
* tarballs with sources
 
  
 +
<!--
 
=== RPM support ===
 
=== RPM support ===
  
 
Each Zero package has ''rpm.spec'' file to support building package on all RPM based distributions that OBS supports. File contains only one line {{Code|%zsugar_spec}} to invoke {{Code|zsugar_spec}} macros which generates spec file content on demand according to current ''0sugar.info'' and ''revision'' files content.
 
Each Zero package has ''rpm.spec'' file to support building package on all RPM based distributions that OBS supports. File contains only one line {{Code|%zsugar_spec}} to invoke {{Code|zsugar_spec}} macros which generates spec file content on demand according to current ''0sugar.info'' and ''revision'' files content.
 +
 +
== Levels ==
 +
 +
The entirely Zero Sugar infrastructure could be split into several levels:
 +
# using spec file, build GNU/Linux distribution packages ([https://build.opensuse.org/ OBS] workflow is primarily supported) to let users install Zero packages from native packaging systems
 +
# using spec file, generate [http://0install.net/ 0isntall] feeds to support [http://0install.net/goals.html#anyonedistrib fully decentralized] deployment model
 +
# do not reinvent the wheel by implementing packaging related features in sugar. For example, for now, sugar manages what activities (i.e. packages) should be launched, from native packages in /usr or from ~/Activities, or sugar supports versioning scheme for activities (simple version numbers vs. dotted versions) or sugar supports MANIFEST files with not yet implemented hashes. All these are regular packaging procedures and it is already implemented. The idea is to reuse 0install as packaging "engine" keeping in mind that:
 +
## its decentralized nature, sugar is all about (re)creating activities that should be some how distributed, using only distributors channels decrease sugar values
 +
## it supports all existed GNU/Linux distribution efforts e.g. there is no need to repackage already packaged, by distros, software, 0install will use PackageKit to install it
 +
-->

Latest revision as of 13:00, 25 November 2010

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.

It was only draft content


Summary

The GNU/Linux distributions integration feature of Zero Sugar is not intended to follow all the requirements of native packages and cannot be reused for distribution of official repositories, i.e., Zero Sugar is NOT a meta-packaging tool.

There are only three major ideas behind native distribution support:

  • make packages, built on OBS, reusable for the 0install deployment model;
  • as a side effect, Zero packages could be installed on GNU/Linux distributions that OBS supports, also, Zero packages might be reused for OBS-based Sugar distributions;
  • Zero Sugar does not support most of the 'devil-in-details' packaging features that make distro people's life so funny.

Each OBS package is generated by the 0sugar tool, and might be built on a bunch of rpm/deb-based distributions within OBS. It is possible to follow regular OBS procedures for Zero packages, e.g., creating links and branching them.