The latest version of this document is available online at: http://www.mancoosi.org/cudf/ebnf
Revision History | |
---|---|
Revision 0.5 | 2010-04-22 |
first public (beta) release, comments are welcome |
Table of Contents
This document provides a non authoritative EBNF grammar for CUDF documents.
The actual grammar is given in Section 2, “Grammar”, whereas some of the additional constraints not grasped by the grammar are documented in Section 3, “Additional constraints”. The authoritative reference for all constraints which apply to the parsing of CUDF documents is [TZ09].
Please refer to [CUDFW] for general information about the CUDF format.
Overall structure | |||||
---|---|---|---|---|---|
|
Flow elements | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Document parts | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Stanzas | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Values: CUDF types | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Values: gory details | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
This section describes some of the additional constraints, not grasped by the grammar of grasped by the grammar of Section 2, “Grammar”, which are relevant to parse CUDF documents.
The overall structure of a CUDF document is a sequence of stanzas,
separated by empty lines. Three types of stanza are distinguished, according
to whether they start with preamble:
, package:
,
or request:
.
Each stanza consists of a list of properties. According to the type of stanza, different properties are allowed. For each property, a type of stanza defines a type schema, that is: whether it is mandatory or not, which type of values are allowed for it (corresponding to one among the Values: CUDF types productions), and (in case it is optional) its default value.
In the reminder you can find a brief summary that contains, for each type of stanza, the relevant property schemata.
Table 1. Type schemata for preamble stanzas
property name | value type | optionality | default value |
---|---|---|---|
property | typedecl | optional | '' |
univ-checksum | string | optional | '' |
status-checksum | string | optional | '' |
req-checksum | string | optional | '' |
Table 2. Type schemata for package stanzas
property name | value type | optionality | default value |
---|---|---|---|
version | posint | required | |
depends | vpkgformula | optional | 'true!' |
conflicts | vpkglist | optional | '' |
provides | veqpkglist | optional | '' |
installed | bool | optional | 'false' |
was-installed | bool | optional | 'false' |
keep | ident [a] | optional | 'none' |
[a] only one of the following identifiers is allowed as a
value for the |
Table 3. Type schemata for request stanzas
property name | value type | optionality | default value |
---|---|---|---|
install | vpkglist | optional | '' |
remove | vpkglist | optional | '' |
upgrade | vpkglist | optional | '' |
In addition to the property schemata listed above, extra schemata can
be allowed, in package stanzas only, when declared in
the preamble using the property
property. Its
typedecl
value defines list of pairs <name, type>,
possibly equipped with a default value in square brackets. When
'enum'
is used instead of a type name, the type of the property
is ident
, but only allows the list of identifiers specified in
parentheses. When the declared property is of type string
, the
default value is specified within double quotes and is subject to
unescaping; see the type definition of
typedecl
, in Section 2.2.2 of [TZ09] for more
information.
Within each stanza of a CUDF document, property names are unique: no two property can share the same name within a single stanza.
Within a CUDF document no two package stanzas can have the same value
following package:
and the same value for the
version
property (i.e. the pair <package name, package
version> is a unique package identifier within the universe).
In the above, all properties have been presented as "one-liners",
i.e. a property span a single physical line of text. In practice and
according to the CUDF specification, logical lines of text can be split
across several physical line of texts by adding newlines ('\n'
)
and indenting all physical lines after the first one of a single white space
(' '
). Physical lines indented that way are called
continuation lines.
The above grammar applies to CUDF files after having juxtaposed continuation lines to their leading lines, removing indentation spaces and their preceding newlines.
[TZ09] Common Upgradeability Description Format (CUDF) 2.0. 2009. Mancoosi project technical report TR003, available on line at: http://www.mancoosi.org/reports/tr3.pdf.
[CUDFW] Common Upgradeability Description Format (CUDF), web page. http://www.mancoosi.org/cudf .