File: B_quickintro.xml

package info (click to toggle)
blends 0.7.11
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 1,260 kB
  • sloc: xml: 4,904; python: 1,226; sh: 705; makefile: 290
file content (237 lines) | stat: -rw-r--r-- 9,360 bytes parent folder | download | duplicates (3)
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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
  <appendix id="QuickIntro">
  <title>Quick intro into building metapackages</title>

<para>
There are several descriptions available how to build Debian packages
in general.  The main resource might be the repository of
<ulink url="http://www.debian.org/doc/packaging-manuals/">
  Debian packaging manuals</ulink> (especially 
<ulink url="http://www.debian.org/doc/packaging-manuals/developers-reference/best-pkging-practices.html">
  developers reference chapter 6, best packaging practices</ulink>).
There are several external packaging HOWTOs for example the one from
<ulink url="http://www-106.ibm.com/developerworks/linux/library/l-debpkg.html">
  Joe 'Zonker' Brockmeier</ulink>.
</para>

  <sect1 id="Dependencies">
  <title>Defining dependencies for metapackages</title>

<para>
This howto describes the building of metapackages by using the
<package>blends-dev</package> package.  It is perfectly possible to
build a metapackage as any other normal Debian package but this HOWTO
has the only purpose to describe the profit you might gain by using
these tools.

    <informalexample>
      <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/tasks .
~> cat tasks/README
~> edit tasks/task1
Description: <varname>short description
 long description as in any debian/control file</varname>

Depends: <varname>dependency1, dependency2, ...</varname>
</programlisting>
    </informalexample>

For each metapackage this skeleton of a <filename>debian/control</filename>
entry is needed.  All necessary information is available in the
directory <filename>/usr/share/doc/blends-dev/examples/tasks</filename>.
</para>
   </sect1>

   <sect1 id="Packaging">
   <title>The packaging directory</title>

<para>
To build any Debian package you always need a directory named
<filename>debian</filename>, which contains a certain set of files.  The
package <package>blends-dev</package> provides a complete set of example
files that only have to be copied and after editing some place
holders are ready to use.
<informalexample>
  <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/debian .
~> cat debian/README
~> edit debian/control.stub
</programlisting>
</informalexample>
Now the variables in the file <filename>control.stub</filename> change the
variables named <varname>_BLEND_</varname>, <varname>_MAINTAINER_</varname> etc. to
match the names of the Debian Pure Blend to be built.  Please note
that the file <filename>debian/control</filename> is and has to be a symbolic
link to <filename>control.stub</filename> to let the
<package>blends-dev</package> tools work.

<informalexample>
  <programlisting>
~> edit debian/rules
</programlisting>
</informalexample>

Also in the <filename>debian/rules</filename> the name of the Blend has to be
inserted where the template contains
<varname>_BLEND_</varname>.  Depending from the way the
<filename>sources.list</filename> should be scanned the options for the
<package>gen-control</package> call can be adjusted. 
</para>
<para>
You have to build the tarball using the command
<informalexample>
  <programlisting>
~> make -f debian/rules get-orig-source
</programlisting>
</informalexample>
For your comfort you might like to create a file
<filename>Makefile</filename> containing
<informalexample>
  <programlisting>
#!/usr/bin/make -f 
include /usr/share/blends-dev/Makefile
</programlisting>
</informalexample>
which enables you to simply use
<informalexample>
  <programlisting>
~> make dist
</programlisting>
</informalexample>
to build the source tarball. This tarball has to be moved to a location
where the metapackages will be built. 
Unpack the tarball there and start the build process
using for instance
<informalexample>
  <programlisting>
~> debuild
</programlisting>
</informalexample>
</para>
<para>
That's all for the very simple case when the metapackages should not
contain user menus.  Even if user menus are suggested they are not
necessary.  The following paragraphs describe how to use the
<package>blends-dev</package> tools to support these menus.
</para>

   </sect1>

   <sect1 id="common-metapackage">
   <title>The common metapackage</title>

<para>
The creation of a common package is optional, but suggested, because it
adds some special features like menus, user groups, and probably more
in the future.  It is automatically built by
<filename>blend-install-helper</filename>, which is called in
<filename>debian/rules</filename>, if the <filename>common</filename> directory exists.
The easiest way to create this is as follows:
<informalexample>
  <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/common .
~> cat common/README
~> edit common/conf common/control common/common.1
</programlisting>
</informalexample>
The variables (<varname>_BLEND_</varname>) in these three files have to be
adjusted to the name of the Debian Pure Blend in question.
This <filename><varname>blend</varname>-config</filename> cares for the initialisation
of the role based menu system and might contain adjustments of the
general configuration inside the <package>blends-common</package>.
</para>
<para>
If the metapackage <varname>blend</varname>-<package>config</package> will be
created according to these rules all other metapackages will depend
automatically from this common package.  For the friends of
<package>auto-apt</package>, a helper
<filename>/usr/bin/</filename><varname>&lt;metapackage-name&gt;</varname> will be
installed as well, which just prints some information about the meta
package.  All in all, the usage of the common package is strongly
suggested to have a common registry for stuff like user roles and
possibly other things that will be implemented in the future.
</para>
   </sect1>
   <sect1 id="metapackage-menus">
   <title>The metapackage menus</title>

<para>
As explained in <xref linkend="menu_tools"/> the metapackages can contain
user menus.  This optional feature can be implemented easily by using
the template from the <package>blends-dev</package> in the following way:

<informalexample>
  <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/menu .
~> cat menu/README
~> edit menu/task1
 <varname>Edit the example to legal menu entries of the
 dependencies of this metapackage</varname>
~> cp menu/task1 menu/<varname>&lt;metapackage name&gt;</varname>
</programlisting>
</informalexample>

A menu file for each task should be created containing valid menu
entries for each dependent package.  The easiest way to obtain those
menu entries is to simply copy the original menu entry files that are
contained in the packages on which the metapackage will depend.
The only thing that has to be changed in these menu entries is the
<package>package</package> field, which has to be changed from
<package>&lt;dependent package&gt;</package> to
<varname>blend</varname>-<package>task</package>.  All other entries
might remain unchanged.  This is a good point to check whether the
menu entries of the packages you depend from are formatted nicely and
print the necessary information (for instance make use of "hints").
Here the metapackage maintainer has a good chance for quality
assurance work, which is also part of the Debian Pure Blends
issue.
</para>
<para>
In principle these menu items could be created automatically either at
metapackage build time or even better in the <filename>postinst</filename>
script of the metapackage because it is granted that the needed menu
files are installed on the system, which is not really necessary on
the metapackage build machine.  This might be implemented in later
versions of <package>blends-dev</package>.  Currently the policy is that
we like to have a little bit of control about the menu entries for the
quality assurance issue mentioned above.  Last, but not least, there are
packages that do not provide a menu entry.  If this is the case
because the package maintainer just forgot it a bug report should be
filed.  On the other hand, there are packages with programs that
provide a command line interface that does not allow a reasonable
menu entry.  A solution for this case is provided in the next
paragraph.
</para>

   </sect1>
   <sect1 id="any-dependency--menus">
   <title>Menu for any dependency</title>

<para>
The idea of the metapackage menu is to provide the user with easily
viewable traces of any installed package that helps solving everyday
tasks.  So if there are packages that do not contain a menu, a screen
with relevant documentation should be provided in a viewer by the
creator of the metapackage.  Such documentation can be created using
the following templates:

<informalexample>
  <programlisting>
~> cp -a /usr/share/doc/blends-dev/examples/docs .
~> cat docs/README
~> edit docs/task1/dep1
 <varname>Provide information about a package &lt;dep1&gt; that is
 a dependency of the metapackage &lt;task1&gt;, but does not
 contain a useful menu entry.</varname>
~> cp docs/task1/dep1 docs/task1/<varname>&lt;dependent pkg&gt;</varname>
~> cp -a docs/task1 docs/<varname>&lt;metapackage name&gt;</varname>
</programlisting>
</informalexample>

This ensures that our users become aware of all interesting packages
on their system.  The documentation files should contain hints to man
pages to read, URLs that should be visited to learn more about the
package or some short introduction how to get started.
</para>
</sect1>
  </appendix>