Changes between Version 3 and Version 4 of Obsolete/MovedToTree/PackageManagement/BuildingPackages


Ignore:
Timestamp:
Jun 27, 2011, 4:18:44 AM (8 years ago)
Author:
bonefish
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Obsolete/MovedToTree/PackageManagement/BuildingPackages

    v3 v4  
    1212The `.PackageInfo` file must be located in the top directory that is archived. A `package` invocation usually looks like that:
    1313{{{
    14 package -C foo-4.5.26-1 foo-x86-4.5.26-1.hpkg
     14package -C foo-4.5.26-1 foo-4.5.26-1-x86.hpkg
    1515}}}
    1616or (packaging a gcc2 build from within the folder):
    1717{{{
    1818cd foo-4.5.26-1
    19 package ../foo-x86_gcc2-4.5.26-1.hpkg
     19package ../foo-4.5.26-1-x86_gcc2.hpkg
    2020}}}
    2121
    2222The argument of the `-C` option specifies the directory whose contents to archive (by default the current directory), the remaining argument is the path of the package file to be built.
    2323
    24 The contents of the .PackageInfo` contains name-value pairs, with the following simple grammar:
     24=== The .PackageInfo ===
     25
     26The contents of the `.PackageInfo` contains name-value pairs, with the following simple grammar:
    2527{{{
    2628package_info    ::= attribute*
    27 attribute       ::= name "=" value_list "\n"
     29attribute       ::= name "=" value_list
    2830value_list      ::= value | ( "[" value* "]" )
    2931}}}
     
    3335The supported attributes are:
    3436 * `name`: The name of the package, not including the package version. Must only contain `<alphanum_underline>` characters.
    35  * `version`: The version of the package. Must be a string of the following form:
    36 {{{
    37 version ::= major [ "." minor [ "." micro ] ] "-" release
    38 major   ::= alphanum_underline+
    39 minor   ::= alphanum_underline+
    40 micro   ::= alphanum_underline+
    41 release ::= integer_between_0_and_255
    42 }}}
     37 * `version`: The version of the package. The string must have the `version` format (see next section).
    4338 * `architecture`: The system architecture the package has been built for. Can be either of:
    4439   - `any`: Any architecture (e.g. a documentation package).
     
    4843 * `description`: A longer description of the package.
    4944 * `vendor`: The name of the person/organization publishing this package.
    50  * `packager`: The name and e-mail address of person that created this package (e.g. "Peter Packman <peter.packman@example.com>").
    51  * `copyright`: The copyright applying to the software contained in this package.
     45 * `packager`: The name and e-mail address of person that created this package (e.g. "Peter Packman <!peter.packman@example.com>").
    5246 * `copyrights`: A list of copyrights applying to the software contained in this package.
    5347 * `licenses`: A list of names of the licenses applying to the software contained in this package.
     
    5751 * `provides`: A list of entities provided by this package. The list elements must have the following format:
    5852{{{
    59 entity          ::= entity_name [ "=" version ]
     53entity          ::= entity_name [ "=" version_ref ] [ ( "compat" | "compatible" ) version_ref ]
    6054entity_name     ::= [ entity_type ":" ] alphanum_underline+
    6155entity_type     ::= alphanum_underline+
    6256}}}
     57   See the next section for the `version_ref` definition.
     58   The first `version_ref` specifies the version of the provided entity. It can be omitted e.g. for abstract resolvables like "web_browser". The `version_ref` after the "compat"/"compatible" string specifies the oldest version the resolvable is backwards compatible with.
    6359 * `requires`: A list of entities required by this package. The list elements must have the following format:
    6460{{{
    65 required_entity         ::= entity_name [ version_operator version ]
     61required_entity         ::= entity_name [ version_operator version_ref ]
    6662version_operator        ::= "<" | "<=" | "==" | "!=" | ">=" | ">"
    6763}}}
     64   See the next section for the `version_ref` definition.
    6865 * `supplements`: A list of entities that are supplemented by this package (i.e. this package will automatically be selected for installation if the supplemented entities are already installed). The list elements must have the `required_entity` format.
    6966 * `conflicts`: A list of entities that this package conflicts with (i.e. only one of both can be installed at any time). The list elements must have the `required_entity` format.
     
    7168 * `replaces`: A list of entities that are being replaced by this package (used if the name of a package changes, or if a package has been split). The list elements must have the `entity_name` format.
    7269
     70
     71=== Version Strings ===
     72
     73Versions strings are used in three contexts: For the package version, for resolvable versions (`provides`), and in dependency version expressions (`requires`, `supplements`, `conflicts`, `freshens`). They are structurally identical, with the exception that the former requires a release component (`version`), while the latter two don't (`version_ref`):
     74{{{
     75version         ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] "-" release
     76version_ref     ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] [ "-" release ]
     77major           ::= alphanum_underline+
     78minor           ::= alphanum_underline+
     79micro           ::= alphanum_underline+
     80pre_release     ::= alpha_underline alphanum_underline*
     81release         ::= integer_between_0_and_99
     82}}}
     83The meaning of the major, minor, and micro version parts is vendor specific. A typical, but not universal (!), convention is to increment the major version when breaking binary compatibility (i.e. version a.d.e is backwards compatible to version a.b.c for all b.c <= d.e), to increment the minor version when adding new features (in a binary compatible way), and to increment the micro version for bug fix releases. There are, however, projects that use different conventions which don't imply that e.g. version 1.4 is backwards compatible with version 1.2. Which convention is used is important for the packager to know, as it is required for a correct declaration of the compatibility versions for the provided resolvables. The compatibility version specifies the oldest version the provided resolvable is backwards compatible with, thus implying the version range requested by a dependent package the resolvable can satisfy. When following the aforementioned convention a resolvable of version 2.4.3 should have compatibility version 2 (or, semantically virtually identical, 2.0.0). Not following the convention 2.4 may be correct instead. If no compatibility version is specified, the resolvable can only satisfy dependency constraints with an exactly matching version.
     84
     85The pre-release part of the version string has a special semantics for comparison. Unlike minor and micro its presence makes the version older. E.g. version R1.0-alpha1 is considered to be older than version R1.0. When both version strings have a pre-release part, that part is compared naturally after the micro part (R1.0.1-alpha1 > R1.0 > R1.0-beta1 > R1.0-alpha2).
     86
     87The release part of the version string is assigned by the packager (not by the vendor). It allows to uniquely identify updated packages of the same vendor version of a software.
     88
     89
     90=== Package File Names ===
     91
     92A package file name should have the following form:
     93{{{
     94file_name       ::= name "-" version "-" architecture ".hpkg"
     95}}}