Standards/YaST2 Repository Metadata/content

From openSUSE

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 ?

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.

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-CD (CD version)
PRODUCT openSUSE-FTP (FTP version)
PRODUCT openSUSE-DVD9 (DVD9 version)

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.