File: README

package info (click to toggle)
germinate 1.5
  • links: PTS
  • area: main
  • in suites: lenny
  • size: 244 kB
  • ctags: 181
  • sloc: python: 2,070; makefile: 35
file content (202 lines) | stat: -rw-r--r-- 7,599 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
LaMont thinks this is fairly complicated ...

We have "seed"s, these are lists of packages which we consider
important to be in the distribution.  We divide these into three sets
for the archive.

	base
	A core set of packages to build a server or desktop on.

	desktop
	The functionality for our CD.
		
	supported
	Everything else we want to support, including the
	build-dependencies of base and desktop.

To form each set, the seed and dependency tree need to be added to
it.  In order to form the supported set, the build-dependency tree
for each set needs to be calculated as well, with any dependencies
resulting added to the build-dependency list to end up in the
supported set.

Example.

	foo; Depends: bar, baz; Build-Depends: quux.
	bar; Depends: wibble; Build-Depends: splat.
	quux; Depends: wobble; Build-Depends: snarf.

If foo is placed in the base seed, then the base dependency list will
contain its dependencies (bar, baz) and their dependencies (wibble).
The base build-dependency list will contain the build-dependencies
of the base seed and dependency list (quux, splat) their dependencies
(wobble) and their build-dependencies (snarf).

So we end up with:
	base seed	foo
	base depends	bar (D foo), baz (D foo), wibble (D bar)
	base build-deps	quux (BD foo), wobble (D quux), snarf (BD quux)

If wobble had dependencies or build-dependencies, they would also be
placed in the base build-dependency list.

You therefore get the following output lists; base.seed (the seed list
itself), base.depends (the dependency list) and base.build-depends
(the build-dependency list).


That was the easy bit...  here's the tricky bit.

Across all three lists for each of the all three sets, every package
only occurs in only one list.  So going back to our previous example,
if a package in the desktop seed depends on 'foo' it won't be added
to the desktop dependency list because it is already in the base
seed.  Likewise if a package in the desktop dependency list depends
on 'bar', it won't be added to the desktop dependency list because
it's already in the base dependency list.

*However* build-dependencies are considered lesser-favoured than
any seed or dependency list, so if a package needed in the desktop seed
or dependency list is in the base build-dependency list it will be
moved out of it and into the list it's needed in.

The actual order of priority is:

	base.seed, base.depends, desktop.seed, desktop.depends,...
	supported.seed, supported.depends, base.build-depends,...
	desktop.build-depends, supported.build-depends

With things being moved out of build-depends and into the right set
(this doesn't affect the others because they're created in the same
order as the priority.)


For each set, the seed and dependency list then get joined together
to form a list named after the set itself.  This isn't quite all
that's needed for supported, so another list is output named
supported+build-depends containing the supported list and the
build-depends lists of the other sets all joined together.

We then join these together to output an "all" list that represents
our entire archive.


So that's the principal set of lists out of the way, but Germinate
also keeps track of when source packages are first used (bearing
in mind that their binaries could be in different sets).  So for
each set, there's a sources list containing the source packages
used in that set and not used in any of higher priority.

There's also a build-sources list for the source packages used by
the build-dependency list but none of the sets themselves nor any
build-sources list of a higher priority.

For maximum greppability, we also get supported+build-depends.sources
and all.sources files.


What happens to the binary packages created by our sources that
we don't place in any set?  I'm glad you asked that, they become the
"extra" seed (the sources list of which is obviously empty so omitted)
have the dependency tree calculated and placed in the extra dependency
list and the build-dependencies in the extra build-dependency list
(although the seeded packages' build-dependencies will already
have been processed, the build-dependencies of the seeded packages'
dependencies may not have been).

All three extra lists are at a lower priority even than the
build dependency lists of the other sets, so a package won't be added
to the extra dependency or build-dependency lists if they are already
in any other.


So we join this up to get extra, extra.sources and extra.build-sources
lists.  We add these to the all lists we made earlier and get
all+extra and all+extra.sources.

These won't all be in the archive, we will almost certainly want to
cherry-pick from extra but there's a lot of crack in it too.


Germinate tries very hard to satisfy package dependencies using the
existing lists, and in any given sequence of alternative packages or
virtual dependency it will generally pick a package already added.
An interesting list of virtual packages and those chosen that provide
that is output in the provides file.


Lastly (oh gods, there's more?!) Germinate waffles quite a bit as it
runs and there's a _germinate_output file containing this.  Lines
beginning '?' are missing or unresolvable packages, '*' are choices
made by Germinate that you might wish to influence and '!' are
problems with the sets.

    ! Duplicated seed: FOO

	FOO has been placed in multiple seeds.  The better seed
	always takes precedence (because it gets processed first).
	
    ! Promoted BAR from SET to BETTER-SET to satisfy FOO

	BAR was in the SET seed, but is a dependency of FOO which
	is in BETTER-SET.  Germinate promotes the package to the
	better set, you can safely remove it from SET if you want
	as FOO depends on it.
	
    * Virtual SET package: WIBBLE
      - WOBBLE
      - SNARFLE

	You placed WIBBLE in SET seed, and it is a virtual package
	(one provided by multiple packages).  Rather than picking
	one, Germinate assumes you want all of the packages that
	provide this and lists the ones it adds.

    * Chose WOBBLE out of WIBBLE to satisfy FOO

	FOO depends on the virtual package WIBBLE, and nothing
	providing that has been seeded or added yet.  Germinate
	randomly chose WOBBLE, the first package in the list,
	to satisfy this dependency.

	You can influence this choice by seeding the one you want.
	
    * Chose BAR to satisfy FOO

	FOO depends on a list a possible packages, and none of them
	has been seeded or added yet.  Germinate randomly chose BAR,
	the first in the list.

	You can influence this choice by seeding the one you want.

    ? Unknown SET package: FOO

	FOO in the SET seed doesn't exist in the Debian archive,
	at least not in unstable/main currently.  Try removing the
	cached Packages and Sources files.

    ? Unknown dependency BAR by FOO

	FOO declares a dependency on BAR which can't be satisfied
	within Debian unstable/main currently.  Try removing the
	cached Packages and Sources files.

    ? Nothing to choose out of WIBBLE to satisfy FOO

	FOO declares a dependency on virtual package WIBBLE, but
	nothing in Debian unstable/main currently provides that.
	Try removing the cached Packages and Sources files.

    ? Nothing to choose to satisfy FOO

	FOO declares a dependency on a list of packages, none of
	which are currently in Debian unstable/main.  Try removing
	the cached Packages and Sources files.

    ? Missing source package: QUUX (for FOO)

	FOO's source package is QUUX, but that is missing from the
	Sources file.  Try removing the Packages and Sources files.


<https://wiki.canonical.com/WartyWarthog/PackageList>