openSUSE:Standards YaST2 Repository Metadata content

Jump to: navigation, search

Template:Navigation Software Repositories



Rationale

What is a product and what makes a product a product ?

Installing openSUSE-10.2 can be done by various means. In the end, the computer system has openSUSE-10.2 installed.

Almost.

Depending on the install media, the resulting set of installed package will vary. You might get additional fonts, translations, games, whatever. The core functionality is the same but there are subtle differences.

And we want to detect these differences for debugging and statistical purposes.
How else would we know where to put our efforts ? On more CDs or better FTP repositories ?

Code11

Icon-warning.png
Warning: There will be changes for Code11. Stay tuned.

Product metadata

The content file at the root directory of the repository defines the product. Internally, the product has a name, a version, a release, and an architecture. Additionally, it has dependencies. In short - its a product resolvable with the same semantics as an RPM package.


Example

CONTENTSTYLE 11
NAME         SUSE_SLES
VERSION      11
RELEASE      0
DISTRIBUTION SUSE Linux Enterprise Server 11.0 (i686)
DESCRDIR     suse/setup/descr
DATADIR      suse
LABEL        SUSE Linux Enterprise Server 11
VENDOR       SuSE Linux Products GmbH
BASEARCHS    i386
RELNOTESURL http://www.novell.com/linux/releasenotes/i386/SUSE-SLES/11/release-notes-sles.rpm
META SHA1 5f4dfc16a5395614af94392382d61e7f4d251c6e  Basis-Devel-10-235.2.i586.pat.gz
META SHA1 ff619b5e2a559c3443dfd07a3319112fa97f9af2  Dom0-10-235.2.i586.pat.gz
...
HASH SHA1 12171caa5bf085ad295c64eb01faaec7b698569f  control.xml
HASH SHA1 2f4eaf960048b9dccc6f47584c0ce31f43332ef1  media.1/info.txt
...
KEY SHA1  17162a96933229a9771ee10c0976bdc047a2f53d  gpg-pubkey-0dfb3188-41ed929b.asc
KEY SHA1  f6accbb18d705bfc104c893cf7dfca1247a33f3c  gpg-pubkey-307e3d54-481f30aa.asc

Current tags documentation

Template:Note

CONTENTSTYLE

  • Must be the first tag of the content file
  • Must have value '11' for Code11, i.e. CONTENTSTYLE 11

NAME will be added

Template:Note

VERSION and RELEASE

  • This would be version-release
  • Same restrictions as for package versions apply
  • Must be comparable (as RPM version-release strings)
  • The version specifies the visible number, the release is internal and starts with 0 for GA and is increased on further rebuilds.
Examples

VERSION 10.2
RELEASE 0 (GA version)

VERSION 10.2
RELEASE 1 (Remastered version)

The factory version

For factory, the version must be different from the released product. Having the same version in factory might be acceptable for a short period of time where factory actually is the to-be-released product - it usually isn't.

So as soon as openSUSE-10.2 is splitted off and new/updated packages appear in factory, its version must be increased.

The factory version must be higher than 10.2 (because development goes on) and lower than 10.3 (we're not there yet).
And changes to the factory tree should be detectable somehow.

So factory will be
VERSION 10.2.1
RELEASE 1
with an increasing release number (starting with 1) every time the factory tree is synched out to the public.

BASEARCHS

  • Space separated list of product architectures. One product per architecture will be created in the available product list.
  • Matches the available product-release packages architectures.

DISTRIBUTION

Some string denoting the distribution. The same string is most probably used in the .rpms to denote the distribution. Usually a composition of name version and flavor.

PATTERNS

  • List of patterns pre-selected by the product.
  • Parsed and evaluated by YaST.

DESCRDIR

  • Where the package lists and patterns are found.

DATADIR

  • Where the packages are found

LABEL

  • Product name for display purposes
  • Translations can additionally be specified as LABEL.locale, i.e. LABEL.de or LABEL.cz

META SHA1

  • Defines the checksum of a resource in DESCRDIR

HASH SHA1

  • Defines a checksum of a unrelated file, relative to the root of the media

KEY SHA1

  • Defines the checksum of a gpg key

VENDOR

  • Defines the vendor of the product
  • It must have the same value as the <vendor> tag of the .prod file
    • If the repository metadata does not provide a vendor information for packages (=Vnd: in the packages file), the package vendor will use this as a fallback

UPDATEURLS

  • Default repository for updates

EXTRAURLS

  • ?

OPTIONALURLS

  • ?

RELNOTESURL

  • Url for the release notes

LINGUAS

  • List of supported languages for this product.
    • If another language is wanted, you need to install e.g. a language add-on (YaST shows a warning if a language not from this list is selected for installation).

LANGUAGE

  • LANGUAGE will be parsed by YaST and defines the default language (if not otherwise set)
    • linuxrc sets the default language when booting from DVD.
    • When installing an add-on product, the language of the base product is used instead.

REPOTAGS

Susemini.png
Version:
satsolver-0.14.16
libzypp-6.31
[BNC Bug377568]
  • The repositories(!) unique identification string.
    • This string can be used to identify duplicate repositories being accessed through different URIs.
    • Merged repositories may provide multiple REPOTAGS entries.

REGISTERPRODUCT

For add-on products. Whether this product needs to be registered.

Obsolete tags

  • PRODUCT will be ignored (replaced by NAME)
  • DISTPRODUCT will be ignored (replaced by DISTRIBUTION)
  • DISTVERSION will be ignored (replaced by DISTRIBUTION)
  • TYPE will be ignored (see identifying the base product)
  • ARCH.* will be ignored (replaced by BASEARCHS)
  • DEFAULTBASE will be ignored (replaced by BASEARCHS)
  • PROVIDES will be ignored
  • REQUIRES will be ignored
  • OBSOLETES will be ignored
    • The 'content' file describes a product, which is represented as a resolvable within satsolver/libzypp.
    • Such a product does not have dependencies, all dependencies are expressed on a package level.
    • A product has a matching -release package, the -release package requires the mandatory packages for the product.
    • There is no replacement for the old REQUIRES tag. Install tools can look at PATTERNS for patterns to be installed.
  • SHORTLABEL will be ignored
    • currently used e.g. by bootloader, but defaults to LABEL if not present
  • YOUURL will be ignored

Not documented/unclear

  • Which tags are mandatory and which are optional?
For libzypp NAME, VERSION, BASEARCHS, VENDOR. The other values are just forwarded to the application. But other components may require other tags as well.
  • Several tags (e.g. NAME) include "Same restrictions as for package names apply" note. What are these restrictions?
See Name Tag of the SUSE package conventions, but applications probably do not care about it...

Code10

The product name

PRODUCT
Is the detailed name of the product, exactly specifying its characteristics
  • No blanks (all existing blank will be converted to underscores)
  • No version (see VERSION)
  • No architecture
  • Same rules as for RPM package names apply
Examples

PRODUCT openSUSE

The product version

VERSION
specifies version-release
  • Must be comparable (as RPM version-release strings)
  • The version specifies the visible number, the release is internal and starts with 0 for GA and is increased on further rebuilds.
Examples

VERSION 10.2-0 (GA version)
VERSION 10.2-1 (Remastered version)

The factory version

For factory, the version must be different from the released product. Having the same version in factory might be acceptable for a short period of time where factory actually is the to-be-released product - it usually isn't.

So as soon as openSUSE-10.2 is splitted off and new/updated packages appear in factory, its version must be increased.

The factory version must be higher than 10.2 (because development goes on) and lower than 10.3 (we're not there yet).
And changes to the factory tree should be detectable somehow.

So factory will be VERSION 10.2.1-1 with an increasing release number (starting with 1) every time the factory tree is synched out to the public.

Dependencies

Provides

For the given examples - openSUSE-10.2 installed via different means - the resulting system is openSUSE-10.2. This fact has to be detectable somehow. And this can be accomplished by dependencies

PROVIDES
Additional tags the product provides (besides its own name)
Example

PROVIDES product:openSUSE = 10.2

There must be an explicit product: prefix since dependencies default to the package name space !

Obsoletes

As a new product is a replacement for all earlier products, this should be expressed by a proper obsoletes dependency.

Example

OBSOLETES product:SUSE_LINUX product:openSUSE < 10.2

openSUSE-10.2 obsoletes all versions of SUSE_LINUX (non-versioned obsoletes!) and all older versions of openSUSE.

See Also

This page does not cover whole content file. See the description of some other parts of content file (but also not complete...)