İçindekiler

1 Patches - Rationale

Patches - Rationale

Differences to Code9

Patches were container for update packages in Code9. There was no way to get to the update packages without the patch.

Patches were supposed to be self contained, without the need for additional packages outside of the patch.

Experience has shown that this was not sufficient.

Changes made for Code10

Update packages are available stand-alone now. In a separate repository.

This especially gives one the opportunity to install the right package directly on new installations.
(When installing a package for the first time with Code9, one always had to install the GA (probably wrong) package first and then run online-update in order to get the right (updated) package).

Patches are not containers any more, but describe how update packages relate to one another and to the bug/solution.

Details

A Code10 patch expresses the need for an update with conditional dependencies.

Internally, this is implemented as two dependencies.

The first is freshens which says if a package update is needed. E.g.

freshens gcc

The second is requires and says which package is needed. E.g.

requires gcc >= 4.1.0-5

Both dependencies combined can be read as If gcc is installed, it should at least be version 4.1.0 release 5

Its not that easy

For single package updates, expressing the freshens/requires directly in the patch works quite well.

However, if multiple packages must be updated and not all of them might be installed (i.e. foo and foo-devel), things dont work that way.

Consider the following (WRONG) example

patch:foo-1.42

freshens foo foo-devel
requires foo >= 1.42 foo-devel >= 1.42

(the notion patch: is used to express different kind of resolvables. So here we have a patch named foo and packages foo and foo-devel. If no kind is given, packages are used)

Freshens are disjunctive, so the patch will be considered if either foo or foo-devel (or both) are installed. Requires however are conjunctive. So together with the patch both foo and foo-devel will be installed.

Which is not what you want.

Atoms to the rescue

The solution to the above problem is to split up the freshens, one for each package.

This is done by inserting helper resolvables, which just express dependencies.

The patch now has

patch:foo-1.42

requires atom:foo-1.42
requires atom:foo-devel-1.42

So it requires two atoms, defined as follows

atom:foo-1.42
freshens foo
requires foo >= 1.42

atom:foo-devel-1.42
freshens foo-devel
requires foo-devel >= 1.42

The trick now is that requirements to atoms with freshens are handled special.

If the freshens does not match, the atom is considered installed (and its requires are not further checked).

If the freshens does match, the atoms requires are evaluated.

So here the patch requires both atoms. If neither packages foo nor foo-devel are installed, the atoms are considered installed (since the freshens did not match).

If either package foo or foo-devel (or both) is installed, the atoms requires to the package is evaluated.

Expressed as conditional dependencies it read as

If package foo is installed it must be at least version 1.42

If package foo-devel is installed, it must be at least version 1.42

back to main page

Last edit in Trac '03/19/06 21:32:35' by 'kkaempf'

Libzypp/Patches/Rationale