/[debian-med]/trunk/community/website/docs/policy.xml
ViewVC logotype

Contents of /trunk/community/website/docs/policy.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 6331 - (show annotations) (download) (as text)
Mon Mar 21 08:39:33 2011 UTC (2 years, 2 months ago) by plessy
File MIME type: text/xml
File size: 45022 byte(s)
Moved SVN build tips from Policy to new SVN tips section.
1 <?xml version='1.0' encoding='UTF-8'?>
2 <?xml-stylesheet type="text/xsl"
3 href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"?>
4 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
5 "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
6 <article xml:base="http://debian-med.alioth.debian.org/">
7 <title>Debian Med Group Policy</title>
8 <articleinfo>
9 <authorgroup>
10 <author>
11 <firstname>Andreas</firstname>
12 <surname>Tille</surname>
13 <contrib>First review </contrib>
14 <email>tille@debian.org</email>
15 </author>
16 <author>
17 <firstname>David</firstname>
18 <surname>Paleino</surname>
19 <contrib>Initial writing </contrib>
20 <email>d.paleino@gmail.com</email>
21 </author>
22 <author>
23 <firstname>Charles</firstname>
24 <surname>Plessy</surname>
25 <contrib>Contributions in 2008</contrib>
26 <email>plessy@debian.org</email>
27 </author>
28 </authorgroup>
29 <releaseinfo>
30 $ policy.xml rev. @REV@ - @DATE@ (@AUTHOR@) $
31 </releaseinfo>
32 </articleinfo>
33 <mediaobject>
34 <objectinfo>
35 <title>Debian Med Group</title>
36 </objectinfo>
37 <imageobject>
38 <imagedata fileref="/img/debian-med.jpg" format="JPG" align="center" />
39 </imageobject>
40 </mediaobject>
41 <sect1 id="introduction">
42 <title>Introduction</title>
43 <para>Debian Med is a <quote><ulink url="http://blends.alioth.debian.org/blends">Debian Pure Blend</ulink></quote>
44 with the aim to develop Debian into an operating system that is particularly
45 well fit for the requirements for medical practice and research.</para>
46 <para>The Debian Med project presents packages that are associated
47 with medicine, pre-clinical research, and life sciences. Its developments
48 are mostly focused on three areas for the moment: medical practice,
49 imaging and bioinformatics.</para>
50 <para>Over the previous years, several initiatives have spawned that
51 address the scientific disciplines like chemistry or bioinformatics.
52 Debian Med is not a competition to these efforts but a platform to
53 present the packages to the community as a Debian Pure Blend.</para>
54 </sect1>
55 <sect1 id="contribute">
56 <title>How to Contribute</title>
57 <para>From the developer to the user, there is a long chain of tasks
58 in which we always welcome participation. First we must keep ourselves
59 informed about the software landscape in biology and medicine. Software
60 to be packaged is chosen according to criteria such as users' need and
61 the consistency of the distribution.</para>
62 <para>Once in Debian, the software is monitored for its quality and bugs
63 are fixed, if possible in collaboration with the upstream maintainer(s).
64 All this work would not be very useful if it remains confidential.</para>
65 <para>We also dedicate some time to advertise it to the world via
66 <ulink url="http://www.debian.org">www.debian.org</ulink>
67 and to ease the integration of new members.</para>
68 <para>Please contact us on <ulink url="mailto:debian-med@lists.debian.org">debian-med@lists.debian.org</ulink>
69 if you want to help to make medical and biological software available
70 to Debian users. Read the <link linkend="membership">Membership</link> section if you're
71 interested in joining us.</para>
72 <para>If you speak a language other than English, you can contribute
73 rightaway with translations of package descriptions at
74 <ulink url="http://ddtp.debian.net">ddtp.debian.net</ulink>.</para>
75 <para>When working on these, you will find immediate targets for improvements
76 of the original English versions, too. For these, though, you need access
77 to Debian Med's source code repository. Very welcome are tutorials that
78 guide Debian users towards the use of packages to their immediate benefit.
79 You may also consider to write respective articles for Magazines, be they
80 online or in print.</para>
81 <sect2 id="membership">
82 <title>Membership</title>
83 <para>To request membership to this group, please go on our
84 <ulink url="http://alioth.debian.org/projects/debian-med">Alioth page</ulink>,
85 or directly follow this <ulink url="http://alioth.debian.org/project/request.php?group_id=30063">link</ulink>.
86 Remember that you must have an Alioth account before requesting
87 membership (see <ulink url="http://alioth.debian.org/account/register.php">here</ulink>
88 to request an Alioth account).</para>
89 </sect2>
90 <sect2 id="readings">
91 <title>Essential readings</title>
92 <itemizedlist>
93 <listitem><para>The <ulink url="http://www.debian.org/doc/debian-policy/">Debian Policy</ulink>: packages must conform to it.</para></listitem>
94 <listitem><para>The <ulink url="http://www.debian.org/doc/developers-reference/">Developers Reference</ulink>: details best packaging practices.</para></listitem>
95 <listitem><para>The <ulink url="http://www.debian.org/doc/maint-guide/">New Maintainer's Guide</ulink>: puts a bit of the two above in practice.</para></listitem>
96 <listitem><para>The <ulink url="http://debian-med.alioth.debian.org/docs/policy.html">Debian Med Policy</ulink> (this document): explains how the work is organised in our team..</para></listitem>
97 </itemizedlist>
98 </sect2>
99 </sect1>
100 <sect1 id="repositories">
101 <title>Repositories</title>
102 <para>We use Subversion (SVN) and Git repositories, hosted on
103 <ulink url="http://alioth.debian.org/">Alioth</ulink>, the hosting
104 facility provided by Debian to free software developers. You can have a look at
105 each repository through Alioth's web interfaces: <ulink url="http://svn.debian.org/wsvn/debian-med/trunk/?rev=0&amp;sc=0">wsvn</ulink>
106 <ulink url="http://svn.debian.org/viewsvn/debian-med">viewsvn</ulink> and
107 <ulink url="http://git.debian.org/">gitweb</ulink>.</para>
108 <para>The Subversion repository is the primary location for our source packages.
109 However, the Git repository is free to use for special cases, for instance when
110 the Subversion tags take a disproportionated size, when the maintainer is
111 much more comfortable with Git than Subversion, when some special features of
112 Git or git-buildpackage are desired, or more simply when the maintainer wants
113 to thake the opportunity to familiarise with Git.
114 </para>
115 <warning id="umask">
116 <para>
117 For most direct operaitons on the repositories in Alioth, an <command>umask</command> of <literal>002</literal> is necessary to avoid problems of missing write permission to the other team members.
118 </para>
119 </warning>
120 <sect2 id="source">
121 <title>Give me the source!</title>
122 <para>
123 To check sources out from our repostitories, please do:
124 <itemizedlist>
125 <listitem>
126 <para>If you are a member of Debian Med or a Debian developer, you have write permission:</para>
127 <blockquote>
128 <para><userinput>
129 <command>svn co</command> <filename class="directory">svn+ssh://user@alioth.debian.org/svn/debian-med/trunk/...</filename>
130 </userinput></para>
131 <para><userinput>
132 <command>git clone</command> <filename class="directory">git+ssh://user@alioth.debian.org/git/debian-med/&lt;package&gt;.git</filename>
133 </userinput></para>
134 </blockquote>
135 <para>You can avoid specifying your Alioth user name by setting it in <filename>~/.ssh/config</filename>:</para>
136 <blockquote>
137 <programlisting>
138 Host *.debian.org
139 User yourusername
140 </programlisting>
141 </blockquote>
142 </listitem>
143 <listitem>
144 <para>For read-only access, the syntax is slightly different:</para>
145 <blockquote>
146 <para><userinput>
147 <command>svn co</command> <filename class="directory">svn://svn.debian.org/svn/debian-med/trunk/...</filename>
148 </userinput></para>
149 <para><userinput>
150 <command>git clone</command> <filename class="directory">git://git.debian.org/git/debian-med/&lt;package&gt;.git</filename>
151 </userinput></para>
152 </blockquote>
153 </listitem>
154 </itemizedlist>
155 </para>
156 <para>
157 Another way to check the sources is through the use of the
158 <command>debcheckout</command> command, from the
159 <ulink url="http://packages.debian.org/devscripts">devscripts</ulink>
160 package.
161 </para>
162 </sect2>
163 <sect2 id="svn-repository-structure">
164 <title>Subversion repository structure</title>
165 <para>The SVN repository is structured as follows:
166 <literallayout>
167 <code>
168 debian-med/
169 └ trunk/
170 ├ community/
171 │ ├ debtags/
172 │ ├ infrastructure/
173 │ └ website/
174 └ packages/
175 &lt;package A&gt;/
176 │ ├ branches/
177 │ ├ tags/
178 │ └ trunk/
179 │ └ debian/
180 &lt;package B&gt;/
181 │ ├ branches/
182 │ ├ tags/
183 │ └ trunk/
184 │ └ debian/
185
186 </code>
187 </literallayout>
188 </para>
189 <note><para>We are currently considering an alternative layout in which all
190 the <filename>trunk</filename>, <filename>tags</filename> and
191 <filename>branches</filename> directories are grouped together, so that developers can checkout trunks without tags.</para></note>
192 </sect2>
193 <sect2 id="subversion-tips">
194 <title>Subversion tips</title>
195 <para>
196 Suggested aliases for
197 <command>svn-buildpackage</command>:<programlisting>
198 alias <command>svn-b</command>='svn-buildpackage -us -uc -rfakeroot --svn-ignore'
199 alias <command>svn-br</command>='svn-b --svn-dont-purge --svn-reuse'
200 alias <command>svn-bt</command>='svn-buildpackage --svn-tag -rfakeroot'</programlisting>
201 </para>
202 <para>
203 To download the upstream sources (if there is a
204 <filename>debian/watch</filename> file): <code><command>echo
205 "origDir=.." &gt;&gt; .svn/deb-layout &amp;&amp; uscan
206 --force-download</command></code>. Alternatively, you can try
207 <code><command>debian/rules get-orig-source</command></code>.
208 </para>
209 <para>
210 If you're a Debian developer or a member of the Debian Med group on
211 Alioth, you can commit your changes: <command>svn commit</command> (also
212 <command>svn ci</command>). Otherwise, you can ask to be added to the
213 group (see the <link linkend="membership">Membership</link> section), or
214 send the result of <command>svn diff</command> to the <ulink
215 url="mailto:debian-med@lists.debian.org">mailing list</ulink>
216 (<command>gzip -9</command> it, if it's too large).
217 </para>
218 </sect2>
219 <sect2 id="git-repository-structures">
220 <title>Common Git repository structures</title>
221 <para>
222 The area on Alioth that contains the Git repositories (<filename
223 class="directory">/git/debian-med</filename>) is not itself structured,
224 but the repositories can be arranged in different possible layouts.
225 </para>
226 <sect3 id="git-buildpackage">
227 <title><command>git-buildpackage</command></title>
228 <para>
229 Most of our packages using Git and stored in Alioth are managed with
230 the <command>git-buildpackage</command> helper. The
231 <literal>master</literal> branch contains the full source package.
232 The <literal>upstream</literal> branch contains the upstream source,
233 after repacking when necessary (non-free files, large convenience code
234 copies, …). The <literal>pristine-tar</literal> contains the data
235 necessary to recreate an original tarball from the repository with a
236 reproducible checksum.
237 </para>
238 <para>
239 Debian releases are tagged with names like
240 <literal>debian/debianversion</literal> and upstream relases are
241 tagged with names like <literal>upstream/upstreamversion</literal>.
242 </para>
243 </sect3>
244 <sect3 id="git-without-tarball">
245 <title>Social Git</title>
246 <para>
247 For some projects, like the ones hosted on <ulink
248 url="http://www.github.com">Github</ulink> or <ulink
249 url="http://www.gitorious.com">Gitorious</ulink>, it may be easier to
250 forward changes made in the Debian package if this one is itself
251 hosted on the same platform, as a clone. In that case, the layouts
252 may vary from package to packages. However, there are good chances
253 that the branch that contains the Debian source package is called
254 <literal>debian</literal>.
255 </para>
256 </sect3>
257 </sect2>
258
259 <sect2 id="git-tips">
260 <title>Git tips</title>
261 <para id="new-repository-with-gbp">
262 Example to create a new git repository for a package where the upstream
263 sources are distributed as file archives (tar, zip, …):<programlisting>
264 <command>mkdir</command> <filename class="directory">package</filename>
265 <command>cd</command> <filename class="directory">package</filename>
266 <command>git init</command>
267 <command>git import-orig</command> <option>--pristine-tar</option> <filename>/path/to/package_version.orig.tar.gz</filename>
268 <command>dh_make</command> <option>-p package_x.y.z</option></programlisting>
269 The above steps will create a repository with the appropriate layout for
270 <command>git-buildpackage</command>, with three branches:
271 <literal>master</literal> (where the Debian development will happen),
272 <literal>pristine-tar</literal> used by the
273 <literal>pristine-tar</literal> tool during the package build process to
274 recreate the original tarball, and <literal>upstream</literal>, which
275 will contain the upstream source.
276 </para>
277 <para id="debcheckout-sets-git-options">
278 To display your name and more nicely in the Git log, you should instruct
279 Git to do so (the <option>--global</option> option is to say Git these
280 are the default parameters for every Git repository you commit to,
281 without it the settings will be per-repository only):<programlisting>
282 <command>git config</command> <option><optional>--global</optional></option> <option>user.name "$DEBFULLNAME"</option>
283 <command>git config</command> <option><optional>--global</optional></option> <option>user.email "$DEBEMAIL"</option></programlisting>
284 </para>
285 <para id="debcheckout-git-track">
286 To clone and follow every branch of a git repository containing a
287 package that is already in the Debian archive, you can use the
288 <command>debcheckout</command> command with its
289 <command><option>--git-track='*'</option></command> option. To restrict
290 the tracked branch to the standard ones used by
291 <command>git-buildpackage</command>, <literal>master upstream
292 pristine-tar</literal> can be passed instead of the wildcard.
293 </para>
294 <para id="git-track-new-branches">
295 Example commands to track new branches: <programlisting>
296 <command>git branch</command> <option>-t <replaceable>upstream</replaceable> <replaceable>origin/upstream</replaceable></option>
297 <command>git branch</command> <option>-t <replaceable>pristine-tar</replaceable> <replaceable>origin/pristine-tar</replaceable></option></programlisting>
298 </para>
299 <para id="git-options-devscripts">
300 If the <package>devscripts</package> variables
301 <varname>DEBEMAIL</varname> and <varname>DEBFULLNAME</varname> are set,
302 <command>debcheckout</command> will set <command>git</command>'s options
303 <varname>user.email</varname> and <varname>user.name</varname>
304 accordingly.
305 </para>
306 <para id="git-add-alioth-branch">
307 To push changes to Alioth, a remote branch needs to be configured. This
308 is done automatically after cloning a repository, for instance with
309 <link linkend="debcheckout-git-track">debcheckout</link>. The default
310 remote branch is called <quote>origin</quote>. Here are example
311 commands to set up Alioth as a remote branch on a freshly created
312 repository:<programlisting>
313 <command>git remote add</command> <literal>origin</literal> <filename class="directory">git+ssh://alioth.debian.org/git/debian-med/package.git</filename></programlisting>
314 </para>
315 <para id="create-git-repository-on-alioth">
316 There is a small script called <command>setup-repository</command> in
317 the <filename class="directory">/git/debian-med</filename> directory on
318 Alioth. <code><command>./setup-repository</command>
319 <option>packagename</option> <option>"Description of the
320 package"</option></code> will create a <filename
321 class="directory">packagename.git</filename> repository on with the
322 proper hooks set up for our team.
323 </para>
324 <para id="push-package-to-alioth">
325 To push the package (make sure you've added the alioth remote!), do the
326 following:<code><command>git push</command> <option>origin
327 master</option></code>. For the first push, it's necessary to specify
328 <option>origin master</option>. The next time you will push, a
329 <command>git push</command> will suffice.
330 </para>
331 <para id="git-push-all-tags">
332 <command>git push</command>this will only push the
333 <literal>master</literal> branch unless it is somehow related to other
334 branches), so be sure to also do a run with <option>--all</option>, and one with <option>--tags</option> if you created new tags.
335 </para>
336 <para id="git-layout-variants">
337 In particular for Git repositories that are not stored in Alioth, the
338 layout can differ from <command>git-buildpackage</command> conventions.
339 In that case, look for instance for a branch called <literal>debian</literal>.
340 </para>
341 <para>
342 If upstream manages his sources with Git, the following makefile
343 script can help producing a version number when no Git tag is
344 available:<programlisting>
345 SOURCEPKG=$(shell dpkg-parsechangelog | sed -n 's/^Source: \(.*\)/\1/p')
346 UPSTREAM=$(shell dpkg-parsechangelog | sed -n 's/^Version: \(.*\)-[^-]*/\1/p')
347 SHA1=$(lastword $(subst ~g, ,$(UPSTREAM)))
348 ORIG=${SOURCEPKG}_${UPSTREAM}.orig.tar.gz
349
350 describe-current-version:
351 git describe --tags upstream | sed 's,^release-,,;s,-,+,;s,-,~,;'
352
353 get-orig-source:
354 git archive --format=tar $(SHA1) | gzip -9 > ../$(ORIG)</programlisting>
355 </para>
356 </sect2>
357
358 <sect2 id="subversion-to-git">
359 <title>Migration of a source package from Subversion to Git.</title>
360 <para>There is no easy way to prepare a Git repository from our Subversion repository that would
361 look like the package was always managed in Git, because we use svn-buildpackage with the
362 mergeWithUpstream property set, which excludes the upstream sources. Nevertheless, the
363 following receipe will genearate a Git repostitory that contains all the history of
364 the debian directory, plus a collection of selected upstream source releases.
365 </para>
366 <itemizedlist>
367 <listitem>
368 <para>Start the conversion as explained in the <ulink url="http://wiki.debian.org/Alioth/Git#ConvertaSVNAliothrepositorytoGit">Alioth/Git</ulink> page of the Debian wiki. To be consistent with a later usage of <command>git-buildpackage</command>, it is preferable to prefix the tag names <quote>debian</quote>. During this conversion, you can take advantage of the file <filename>/trunk/community/infrastructure/comitters</filename> in the Subversion repository, and expand it if necessary.</para>
369 </listitem>
370 <listitem>
371 <para>Import of the upstream original tarballs that you find relevant, for instance the ones that were part of a stable release). When this paragraph was written, it was necessary to follow special instruction detailed in <ulink url="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471560">bug 471560</ulink>.
372 </para>
373 </listitem>
374 <listitem>
375 <para>Upload to alioth.debian.org/git/debian-med and set up the hooks and other meta-data as explained in the <ulink url="http://wiki.debian.org/Alioth/Git">Alioth/Git</ulink> page of the Debian wiki.
376 </para>
377 </listitem>
378 </itemizedlist>
379 <para>It is also possible to prepare a Git repository containing some of the package's history using the command <command>git-import-dscs --debsnap</command> from the helper toolkit <command>git-buildpackage</command>. This will download all the versions of a package available in <ulink url="http://snapshot.debian.org">snapshots.debian.org</ulink> and create tags for each of them. Note that as this paragraph is written, the tool is not aware that <emphasis>backports</emphasis> should be a different branch</para>
380 </sect2>
381 <sect2 id="updating-git-package">
382 <title>Updating a source package managed with Git</title>
383 <para>Most source packages maintained as Git repositories in Debian Med are using the <command>git-buildpackage</command> helper toolkit. In doubt, try this one first.</para>
384 <para><command>git-buildpackage</command>'s command <command>git-import-orig</command> allows very easy update of the <emphasis>upstream</emphasis> branch when the original sources are distributed as a compressed archive. Its option <command>--pristine-tar</command> is useful for stablizing the MD5 sum of the “<filename>orig.tar.gz</filename>” produced when building a source package from the repository alone (not doing so results in archive rejection of package updates). With recent versions of git-buildpackage, it is often unnecessary to rename the freshly downloaded original upstream archive.</para>
385 </sect2>
386 </sect1>
387 <sect1 id="packaging">
388 <title>Packaging</title>
389 <sect2 id="itp">
390 <title>Announcing intent to package</title>
391 <para>If you intent to work on a Debian package you should follow
392 the <ulink url="http://www.debian.org/devel/wnpp/#l1">normal Debian rules</ulink> and file a <acronym>WNPP</acronym> bug report.</para>
393 <para>It is a good idea to keep the Debian Med mailing list
394 <ulink url="mailto:debian-med@lists.debian.org">debian-med@lists.debian.org</ulink>
395 <ulink url="http://www.debian.org/Bugs/Reporting#xcc"> in CC</ulink> and to set it
396 as the owner of the ITP to keep your co-workers informed. This will ensure that we notice
397 if for some reason the package has not been uploaded.</para>
398 <para>In addition, please add the package to the <quote>task</quote> file where it fits
399 the best, and document your ITP number using the <command>WNPP</command> field name.</para>
400 </sect2>
401 </sect1>
402 <sect1 id="tasks">
403 <title>Tasks</title>
404 <para>The Debian Med <ulink url="http://blends.alioth.debian.org/blends">Debian Pure Blend</ulink> is organised by <ulink url="http://debian-med.alioth.debian.org/tasks/index">tasks</ulink>, that group packages around broad themes such as <ulink url="http://debian-med.alioth.debian.org/tasks/imaging">medical imaging</ulink> for instance. The tasks list programs that are already packaged in Debian as well as packages in preparation.</para>
405 <para>The tasks files are not hosted in the Debian Med repositories, but in the Debian Blends repository. Nevertheless, all members of the Debian Med project on the Alioth forge have write access to the Blends subversion repository. You can easily check out its sources with the command <command>debcheckout -a debian-med</command>.</para>
406 <para>The syntax of the tasks files is very similar to Debian control files, and described in the <ulink url="http://blends.alioth.debian.org/blends/ch-sentinel.en.html">Debian Blends website</ulink>.</para>
407 </sect1>
408 <sect1 id="policy">
409 <title>Policy</title>
410 <sect2 id="debian-control">
411 <title><filename>debian/control</filename></title>
412 <orderedlist>
413 <listitem>
414 <formalpara>
415 <title>Section</title>
416 <para>Should be <quote>science</quote> for the source package.</para>
417 </formalpara>
418 </listitem>
419
420 <listitem>
421 <formalpara>
422 <title>Priority</title>
423 <para>Should be <quote>optional</quote> unless forbidden by the Debian policy (see section 2.5). Packages of priority <quote>extra</quote> are excluded from some QA tests.</para>
424 </formalpara>
425 </listitem>
426
427 <listitem>
428 <formalpara>
429 <title>Maintainer</title>
430 <para>Maintainer should be Debian Med Packaging Team <email>debian-med-packaging@lists.alioth.debian.org</email>. Please subscribe to this list if you list yourself in the <code>Uploaders:</code> field of one of Debian Med's packages. You can refer to the <ulink url="http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org">QA page</ulink> corresponding to this email to gather information about the packages.</para>
431 </formalpara>
432 </listitem>
433
434 <listitem>
435 <formalpara>
436 <title>Upload by Debian Maintainers</title>
437 <para>Should be enabled with the field <code>DM-Upload-Allowed: yes</code>. This means that when an Uploader becomes Debian Maintainer, he will immediately get the possibility to upload the package to Debian. Please consider this when you sponsor packages in which some Uploaders are added.</para>
438 </formalpara>
439 </listitem>
440
441 <listitem>
442 <formalpara>
443 <title>Uploaders</title>
444 <para>Please add yourelf as an uploader when you have a significant interest in a package. Being Uploader means that you are expected to answer to the bug reports. For more occasional works, you can do a <ulink url="http://www.debian.org/doc/developers-reference/pkgs#nmu-team-upload">team upload</ulink>.
445 </para>
446 </formalpara>
447 </listitem>
448
449 <listitem>
450 <formalpara>
451 <title>Standards-Version</title>
452 <para>Please always use the latest unless there are concerns for backporting. If no changes are needed, please indicate this fact in the changelog, and increment the value of the field.</para>
453 </formalpara>
454 </listitem>
455
456 <listitem>
457 <formalpara>
458 <title>Homepage</title>
459 <para>should be documented whenever possible</para>
460 </formalpara>
461 </listitem>
462
463 <listitem>
464 <formalpara>
465 <title>Vcs-Svn: and Vcs-Browser:</title>
466 <para>Please use the following templates:
467 <programlisting>
468 Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/&lt;package&gt;/trunk/
469 Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/&lt;package&gt;/trunk/?rev=0&amp;sc=0
470 </programlisting>or
471 <programlisting>
472 Vcs-Git: git://git.debian.org/git/debian-med/&lt;package&gt;.git
473 Vcs-Browser: http://git.debian.org/?p=debian-med/&lt;package&gt;.git
474 </programlisting>
475 </para>
476 </formalpara>
477 </listitem>
478 </orderedlist>
479 </sect2>
480
481 <sect2 id="debian-copyright">
482 <title><filename>debian/copyright</filename></title>
483 <para>We use the <ulink url="http://wiki.debian.org/Proposals/CopyrightFormat">proposed machine-readable format</ulink> for the <filename>debian/copyright</filename> file. The <computeroutput>Source</computeroutput> field does not need to contain the full URL to the particular version that is being packaged, since this can be determined by the <command>uscan</command> program with the <filename>debian/watch</filename> file. Please list yourself in the <computeroutput>Files: debian/*</computeroutput> section if you think that your contributions are not trivial and therefore subjected to copyright. Please chose a license that is compatible with the program you package. You can also use <quote>same as if it were in the public domain</quote> or <quote>same as the packaged program itself</quote>.</para>
484 </sect2>
485
486 <sect2 id="debian-changelog">
487 <title><filename>debian/changelog</filename></title>
488 <para>Packages hosted in our Subversion repository, that have been modified but not uploaded must use <emphasis>UNRELEASED</emphasis> as a distribution name. This can be done automatically by declaring <emphasis>DEBCHANGE_RELEASE_HEURISTIC=changelog</emphasis> in <filename>~/.devscripts</filename> and using <command>dch</command>.</para>
489 </sect2>
490 <sect2 id="debian-readme-source">
491 <title><filename>debian/README.source</filename></title>
492 <para>This file is recommended by the Policy (<ulink url="http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource">§ 4.14</ulink>) from version 3.8.0 for documenting source package handling. Please follow the recommendation. For instance, this file is needed when we use a patch system, when the upstream sources are in another format than gzipped tar achive, when we repack the sources,…</para>
493 </sect2>
494
495 <sect2 id="debhelper">
496 <title>Debhelper</title>
497 <para>Debhelper uses compatibility levels to control the behaviour of its commands. We currently recommend to use the level <emphasis>8</emphasis> which
498 is available in current <emphasis>Stable</emphasis> (Squeeze) and backported to <emphasis>Oldstable</emphasis>. However, there is no urgent need to
499 touch packages only because it has an older Debhelper version.</para>
500 <para>
501 It is strongly recommended to use the short <emphasis>dh</emphasis> notation in <filename>debian/rules</filename> files which makes code factorisation very
502 simple and easy to understand the packaging for other members of the team. Even complex packaging becomes quite transparant this way.
503 </para>
504 </sect2>
505
506 <sect2 id="cdbs">
507 <title>CDBS</title>
508 <para>Before the short <emphasis>dh</emphasis> notation of debhelper existed CDBS was the only way to factorise code in <filename>debian/rules</filename> files.
509 So it was recommended in the past but it turned out that CDBS is badly documented and recently introduced incompatible changes. So it is sometimes reasonable
510 to switch from CDBS to <emphasis>dh</emphasis> if some problems in the packaging might occure.</para>
511 <para>It is technically possible to build CDBS packages using Debhelper without the <filename>debian/compat</filename> file. Please do not, and always include such a file according to the above guidelines.</para>
512 </sect2>
513
514 <sect2 id="vcs">
515 <title>Version control systems</title>
516 <para>
517 We are currently using two different version control systems, Subversion and Git.
518 </para>
519 <sect3 id="vcs-svn">
520 <title>Source package stored in a Subversion repository</title>
521 <para>
522 <emphasis>This section is in construction, see <link linkend="svn-inject">below</link> for te moment.</emphasis>
523 </para>
524 </sect3>
525 <sect3 id="vcs-git">
526 <title>Source package stored in a Git repository</title>
527 <para>
528 Git repositories managed with a helper tool should announce it. For instance, to show that <command>git-buildpackage</command> is used, the package can contain a configuration file in <filename>debian/gbp.conf</filename>.
529 </para>
530 </sect3>
531 </sect2>
532
533 <sect2 id="new-package">
534 <title>Injecting a new package</title>
535 <sect3 id="svn-inject">
536 <title>Subversion</title>
537 <para>To inject a new package to the SVN repository, you must have
538 write access to it; i.e. you must be a member of the <emphasis>debian-med</emphasis> group on Alioth.</para>
539 <para>You can inject a new package only after successfully building
540 it with <command>dpkg-buildpackage</command> (or any wrapper around it). We use the MergeWithUpstream workflow, so please keep all the modifications in the <filename>debian</filename> directory, and use the <option>-o</option> of <command>svn-buildpackage</command>, as in the following example:</para>
541 <blockquote>
542 <para><userinput>
543 <command>svn-inject</command>
544 <option>-o</option>
545 <filename>package.dsc</filename>
546 <filename class="directory">svn+ssh://user@alioth.debian.org/svn/debian-med/trunk/packages/</filename>
547 </userinput></para>
548 </blockquote>
549 <para>The <command>svn-inject</command> command is found in the
550 <command>svn-buildpackage</command> package (just
551 <command>apt-get</command> it).</para>
552 <para>Once you injected a new package please make sure that it is
553 mentioned in the apropriate tasks file in the package source of the
554 debian-med Blend package in SVN. Normally maintainer watch the changes in
555 the Debian Med packaging pool but it helps if the maintainer of a
556 certain package verifies that everything is in the right place.</para>
557 </sect3>
558 <sect3 id="new-git-repo">
559 <title>New package stored in a Git repository.</title>
560 <para>
561 Git repositories should be stored in the
562 <filename class="directory">/git/debian-med</filename> directory on Alioth and created with the <link
563 linkend="create-git-repository-on-alioth"><command>setup-repository</command></link>
564 script available there.
565 </para>
566 </sect3>
567 </sect2>
568 <sect2 id="building-and-tagging">
569 <title>Building and tagging the packages</title>
570 <sect3 id="building">
571 <title>Building the packages</title>
572 <sect4 id="building-git">
573 <title>Git</title>
574 <para>You should use <command>git-buildpackage</command> to build the
575 packages with git. Be sure to run it from the <quote>master</quote>
576 branch.</para>
577 <para>Unfortunately, by default <command>git-buildpackage</command>
578 builds the package without using any chroot (the same as
579 <command>svn-buildpackage</command>), but it's configurable to run
580 it inside a chroot.</para>
581 <para>You can use this configuration file, <filename>~/.gbp.conf</filename>:</para>
582 <blockquote>
583 <programlisting>[DEFAULT]
584 builder = ~/bin/git-pbuilder
585 cleaner = fakeroot debian/rules clean
586 pristine-tar = True
587
588 [git-buildpackage]
589 # use this for more svn-buildpackage like behaviour:
590 export-dir = ../build-area/
591 tarball-dir = ../tarballs/</programlisting>
592 </blockquote>
593 <para>With this configuration file you're specifying that
594 <command>git-buildpackage</command> will use <filename>~/bin/git-pbuilder</filename>
595 as the builder script. This is an example script you can use:</para>
596 <blockquote>
597 <programlisting>#!/bin/sh
598 set -e
599
600 pdebuild --pbuilder cowbuilder --debbuildopts "-i\.git -I.git $*"
601 rm ../*_source.changes</programlisting>
602 </blockquote>
603 <para>This will build the package inside the default cowbuilder chroot, while
604 passing any more parameters directly do <command>dpkg-buildpackage</command>.</para>
605 </sect4>
606 </sect3>
607 <sect3 id="tagging">
608 <title>Tagging packages</title>
609 <sect4 id="tagging-subversion">
610 <title>Subversion</title>
611 <para>It may happen that a package version has been uploaded to Debian
612 repositories, and you forgot to tag the last build with</para>
613 <blockquote>
614 <para><userinput>
615 <command>svn-buildpackage --svn-tag</command>
616 </userinput></para>
617 </blockquote>
618 <para>
619 You can tag this package also retroactively. A first step, creating
620 the tags directory, can be achieved in two ways:
621 <itemizedlist>
622 <listitem>
623 <para>create it locally (it is a sibling of <filename class="directory">trunk/</filename>), and commit:</para>
624 <blockquote>
625 <para><userinput>
626 <command>svn mkdir</command> <filename class="directory">tags</filename>
627 </userinput></para>
628 <para><userinput>
629 <command>svn commit</command>
630 </userinput></para>
631 </blockquote>
632 </listitem>
633 <listitem>
634 <para>create it remotely:</para>
635 <blockquote>
636 <para><userinput>
637 <command>svn mkdir</command> <filename class="directory">svn+ssh://user@svn.debian.org/svn/debian-med/trunk/packages/&lt;package&gt;/tags</filename>
638 </userinput></para>
639 </blockquote>
640 </listitem>
641 </itemizedlist>
642 </para>
643 <para>After the tags directory has been created, you're ready to tag the
644 package:</para>
645 <blockquote>
646 <para><userinput>
647 <command>svn-buildpackage --svn-tag-only --svn-no-autodch</command>
648 </userinput></para>
649 </blockquote>
650 <para>(--svn-no-autodch avoids <filename>debian/changelog</filename> to be marked as UNRELEASED).</para>
651 </sect4>
652 <sect4 id="tagging-git">
653 <title>Git</title>
654 <para>Tagging a release with git is pretty straightforward:</para>
655 <blockquote>
656 <para><userinput>
657 <command>git tag</command>
658 <option>tagname</option>
659 </userinput></para>
660 </blockquote>
661 <para>The tag names usually follow the scheme <quote>debian/x.y-z</quote>,
662 this will ensure compatibility with other tools as well (like
663 <command>git import-dsc</command>).</para>
664 <para>You can also easily retroactively make tags:</para>
665 <blockquote>
666 <para><userinput>
667 <command>git checkout</command>
668 <option>&lt;commit hash&gt;</option>
669 </userinput></para>
670 </blockquote>
671 <para>You're now at the point in history when you released the package.
672 Just tag it as you would normally do.</para>
673 <para>After tagging, be sure to <command>git push --tags</command>, so that
674 other people can benefit from it too.</para>
675 </sect4>
676 </sect3>
677 </sect2>
678 <sect2 id="patches">
679 <title>Handling patches</title>
680 <para>
681 Often happens that the upstream code doesn't fit well into the
682 Debian distribution: be this wrong paths, missing features, anything
683 that implies editing the source files. When you directly edit
684 upstream's source files, your changes will be put into a .diff.gz file
685 if you use the <literal>1.0</literal> source format and in a monolithic
686 patch if you use the <literal>3.0 (quilt)</literal> format. To better
687 organise the patches and group the by function, please use a patch
688 handling system which keeps patches under the <filename
689 class="directory">debian/patches</filename> directory.
690 </para>
691 <para>
692 The <literal>3.0 (quilt)</literal> Dpkg source format provides its own
693 patch system. Apart from this, the most popular is
694 <command>quilt</command>. <emphasis>simple-patchsys</emphasis>, from
695 the <package>CDBS</package> package, is deprecated since version
696 <literal>0.4.85</literal>. <command>dpatch</command> has been popular
697 as well, but is not compatible with the <literal>3.0 (quilt)</literal>
698 source format. Please don't use any other patch system in Debian Med,
699 unless absolutely necessary.
700 </para>
701 <sect3 id="quilt">
702 <title>Using <command>quilt</command></title>
703 <para>Using quilt is rather easy.</para>
704 <para>First, make sure you have correctly setup quilt: open
705 <filename>.quiltrc</filename> in your home directory (create
706 it if you don't have one), and make sure it looks like this:</para>
707 <blockquote>
708 <programlisting>QUILT_DIFF_ARGS="--no-timestamps --no-index"
709 QUILT_REFRESH_ARGS="--no-timestamps --no-index"
710 QUILT_PATCHES="debian/patches"</programlisting>
711 </blockquote>
712 <para>After this, you're ready to start working with quilt.</para>
713 <sect4 id="quilt-create">
714 <title>Creating a patch</title>
715 <para>To create a patch, use the <command>new</command> command.
716 Run:</para>
717 <blockquote>
718 <para><userinput>
719 <command>quilt new</command> <filename>&lt;patch_name&gt;.patch</filename>
720 </userinput></para>
721 </blockquote>
722 <para>This will create (if it doesn't exist yet) a
723 <filename>debian/patches/series</filename> file, which
724 contains all the patches to be applied by quilt. Moreover,
725 the new patch is also the topmost (the currently
726 applied).</para>
727 <para>Now start editing files, with:</para>
728 <blockquote>
729 <para><userinput>
730 <command>quilt edit</command> <filename>&lt;file&gt;</filename>
731 </userinput></para>
732 </blockquote>
733 <para>and repeat the process for each file the patch is
734 involved with. At the end, run</para>
735 <blockquote>
736 <para><userinput>
737 <command>quilt refresh</command>
738 </userinput></para>
739 </blockquote>
740 <para>This will compare the noted state of the edited files
741 with the current state, and will produce a patch in
742 <filename>debian/patches</filename>. Remember: the patch
743 is currently applied (you can check this with
744 <command>quilt applied</command>).</para>
745 </sect4>
746 <sect4 id="quilt-apply">
747 <title>Applying and unapplying patches</title>
748 <para>Just two easy commands to do the job:</para>
749 <itemizedlist>
750 <listitem><para><command>quilt pop</command> will unapply the topmost patch.</para></listitem>
751 <listitem><para><command>quilt push</command> will apply the next patch in debian/patches/series.</para></listitem>
752 </itemizedlist>
753 <para>You can just add a "-a" flag to the commands above, to
754 respectively apply/unapply all patches in the series.</para>
755 <tip>
756 <para>You can check which patches are applied/unapplied
757 with, respectively, <command>quilt applied</command> and
758 <command>quilt unapplied</command>.</para>
759 </tip>
760 </sect4>
761 <sect4 id="quilt-edit">
762 <title>Editing patches</title>
763 <para>To edit a patch, first make it the topmost:</para>
764 <blockquote>
765 <para><userinput>
766 <command>quilt push</command> <filename>&lt;patch_name&gt;</filename>
767 </userinput></para>
768 </blockquote>
769 <para>If the patch is already applied, but is not the topmost,
770 run <command>quilt pop</command> until it becomes the currently
771 applied one.</para>
772 <para>You can now run <command>quilt edit</command> on the files
773 you want to change, and, when you're done, <command>quilt
774 refresh</command>.</para>
775 </sect4>
776 <sect4 id="quilt-rename">
777 <title>Renaming patches</title>
778 <para>Sometimes it's useful to rename a patch. Without
779 any hassle, do:</para>
780 <blockquote>
781 <para><userinput>
782 <command>quilt rename -P</command> <filename>&lt;old_name&gt;.patch</filename>
783 <filename>&lt;new_name&gt;.patch</filename>
784 </userinput></para>
785 </blockquote>
786 </sect4>
787 <sect4 id="quilt-other">
788 <title>Other commands</title>
789 <para>Please see <command>man 1 quilt</command> to have a
790 comprehensive list of commands.</para>
791 </sect4>
792 <sect4 id="quilt-integration">
793 <title>Integration in the build process</title>
794 <para>Add in the very first part of <filename>debian/rules</filename>
795 (i.e. before the targets), the line:</para>
796 <blockquote>
797 <programlisting>include <filename class="headerfile">/usr/share/quilt/quilt.make</filename></programlisting>
798 </blockquote>
799 <para>Please use this to import patch and unpatch rules instead of writing them, and remember to add the needed dependencies to its
800 targets:</para>
801 <blockquote>
802 <programlisting>...
803 build: patch build-stamp
804 build-stamp: configure
805 ...</programlisting>
806 </blockquote>
807 <para>This kind of dependency will ensure that if you also
808 patch the build system, you get a working patched build
809 process.</para>
810 <caution>
811 <para>Don't also put configure as a dependency of
812 build (leave it in build-stamp): that may cause problems
813 during parallel buildings (i.e. the -j flag of make).</para>
814 </caution>
815 <para>Now add a dependency to the clean target:</para>
816 <blockquote>
817 <programlisting>...
818 clean: unpatch
819 ...</programlisting>
820 </blockquote>
821 <para>If you've also patched the build system, using upstream's
822 clean target might fail. This is what you should do:</para>
823 <blockquote>
824 <programlisting>...
825 clean: clean-patched unpatch
826 clean-patched:
827 ...</programlisting>
828 </blockquote>
829 <para>Obviously, you could always use an approach like this,
830 but it's an useless complication if you don't patch the build
831 system, and you should keep <filename>debian/rules</filename>
832 the simplest you can.</para>
833 </sect4>
834 </sect3>
835 <sect3 id="dpatch">
836 <title>Using <command>dpatch</command></title>
837 <sect4 id="dpatch-create-patch">
838 <title>Creating a patch</title>
839 <para>dpatch-edit-patch</para>
840 </sect4>
841 <sect4 id="dpatch-apply-unapply">
842 <title>Applying and unapplying patches</title>
843 <para>apply(-all), unapply(-all), status</para>
844 </sect4>
845 <sect4 id="dpatch-edit-patch">
846 <title>Editing patches</title>
847 <para>dpatch-edit-patch</para>
848 </sect4>
849 <sect4 id="dpatch-rename-patch">
850 <title>Renaming patches</title>
851 <para>Is this possible?</para>
852 </sect4>
853 <sect4 id="dpatch-other">
854 <title>Other commands</title>
855 <para>Please see <command>man 1 dpatch</command> for a
856 comprehensive list of commands.</para>
857 </sect4>
858 <sect4 id="dpatch-integration">
859 <title>Integration in the build process</title>
860 <para>Follow the instructions for quilt and adapt the path of
861 inclusion to <filename class="headerfile">/usr/share/dpatch/dpatch.make</filename></para>
862 </sect4>
863 </sect3>
864 </sect2>
865 </sect1>
866 </article>

  ViewVC Help
Powered by ViewVC 1.1.5