[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]
Debian's quality is largely due to the Debian Policy, which
defines explicit baseline requirements which all Debian packages must fulfill.
Yet there is also a shared history of experience which goes beyond the Debian
Policy, an accumulation of years of experience in packaging. Many very
talented people have created great tools, tools which help you, the Debian
maintainer, create and maintain excellent packages.
This chapter provides some best practices for Debian developers. All recommendations are merely that, and are not requirements or policy. These are just some subjective hints, advice and pointers collected from Debian developers. Feel free to pick and choose whatever works best for you.
debian/rules
The following recommendations apply to the debian/rules file.
Since debian/rules controls the build process and selects the
files which go into the package (directly or indirectly), it's usually the file
maintainers spend the most time on.
The rationale for using helper scripts in debian/rules is that
they let maintainers use and share common logic among many packages. Take for
instance the question of installing menu entries: you need to put the file into
/usr/lib/menu (or /usr/lib/menu for executable binary
menufiles, if this is needed), and add commands to the maintainer scripts to
register and unregister the menu entries. Since this is a very common thing
for packages to do, why should each maintainer rewrite all this on their own,
sometimes with bugs? Also, supposing the menu directory changed, every package
would have to be changed.
Helper scripts take care of these issues. Assuming you comply with the conventions expected by the helper script, the helper takes care of all the details. Changes in policy can be made in the helper script; then packages just need to be rebuilt with the new version of the helper and no other changes.
Overview of Debian Maintainer Tools, Appendix A
contains a couple of different helpers. The most common and best (in our
opinion) helper system is debhelper. Previous helper systems,
such as debmake, were "monolithic": you couldn't pick
and choose which part of the helper you found useful, but had to use the helper
to do everything. debhelper, however, is a number of separate
little dh_* programs. For instance, dh_installman
installs and compresses man pages, dh_installmenu installs menu
files, and so on. Thus, it offers enough flexibility to be able to use the
little helper scripts, where useful, in conjunction with hand-crafted commands
in debian/rules.
You can get started with debhelper by reading
debhelper(1), and looking at the examples that come with the
package. dh_make, from the dh-make package (see dh-make, Section A.3.3), can
be used to convert a "vanilla" source package to a
debhelperized package. This shortcut, though, should not convince
you that you do not need to bother understanding the individual
dh_* helpers. If you are going to use a helper, you do need to
take the time to learn to use that helper, to learn its expectations and
behavior.
Some people feel that vanilla debian/rules files are better, since
you don't have to learn the intricacies of any helper system. This decision is
completely up to you. Use what works for you. Many examples of vanilla
debian/rules files are available at http://arch.debian.org/arch/private/srivasta/.
Big, complex packages may have many bugs that you need to deal with. If you
correct a number of bugs directly in the source, and you're not careful, it can
get hard to differentiate the various patches that you applied. It can get
quite messy when you have to update the package to a new upstream version which
integrates some of the fixes (but not all). You can't take the total set of
diffs (e.g., from .diff.gz) and work out which patch sets to back
out as a unit as bugs are fixed upstream.
Unfortunately, the packaging system as such currently doesn't provide for
separating the patches into several files. Nevertheless, there are ways to
separate patches: the patch files are shipped within the Debian patch file
(.diff.gz), usually within the debian/ directory.
The only difference is that they aren't applied immediately by dpkg-source, but
by the build rule of debian/rules. Conversely, they
are reverted in the clean rule.
dbs is one of the more popular approaches to this. It does all of
the above, and provides a facility for creating new and updating old patches.
See the package dbs for more information and
hello-dbs for an example.
dpatch also provides these facilities, but it's intended to be
even easier to use. See the package dpatch for documentation and
examples (in /usr/share/doc/dpatch).
A single source package will often build several binary packages, either to
provide several flavors of the same software (e.g., the vim source
package) or to make several small packages instead of a big one (e.g., so the
user can install only the subset needed, and thus save some disk space).
The second case can be easily managed in debian/rules. You just
need to move the appropriate files from the build directory into the package's
temporary trees. You can do this using install or
dh_install from debhelper. Be sure to check the
different permutations of the various packages, ensuring that you have the
inter-package dependencies set right in debian/control.
The first case is a bit more difficult since it involves multiple recompiles of
the same software but with different configuration options. The
vim source package is an example of how to manage this using an
hand-crafted debian/rules file.
debian/control
The following practices are relevant to the debian/control file.
They supplement the Policy
on package descriptions.
The description of the package, as defined by the corresponding field in the
control file, contains both the package synopsis and the long
description for the package. General guidelines
for package descriptions, Section 6.2.1 describes common guidelines for
both parts of the package description. Following that, The package synopsis, or short description, Section
6.2.2 provides guidelines specific to the synopsis, and The long description, Section 6.2.3 contains
guidelines specific to the description.
The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user.
Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem.
How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — "GNOME" or "KDE" is fine, since users are probably familiar with these terms, but "GTK+" is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them.
Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about.
References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, use "X Window System", "X11", or "X"; not "X Windows", "X-Windows", or "X Window". Use "GTK+", not "GTK" or "gtk". Use "GNOME", not "Gnome". Use "PostScript", not "Postscript" or "postscript".
If you are having problems writing your description, you may wish to send it
along to [email protected]
and request feedback.
The synopsis line (the short description) should be concise. It must not repeat the package's name (this is policy).
It's a good idea to think of the synopsis as an appositive clause, not a full sentence. An appositive clause is defined in WordNet as a grammatical relation between a word and a noun phrase that follows, e.g., "Rudolph the red-nosed reindeer". The appositive clause here is "red-nosed reindeer". Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite ("the") or indefinite ("a" or "an").
It might help to imagine that the synopsis is combined with the package name in the following way:
package-name is a synopsis.
Alternatively, it might make sense to think of it as
package-name is synopsis.
or, if the package name itself is a plural (such as "developers-tools")
package-name are synopsis.
This way of forming a sentence from the package name and synopsis should be considered as a heuristic and not a strict rule. There are some cases where it doesn't make sense to try to form a sentence.
The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis.
The long description should consist of full and complete sentences.
The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical.
The following paragraphs should answer the following questions: Why do I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., "if you need X, use Y instead")? Is this package related to other packages in some way that is not handled by the package manager (e.g., "this is the client for the foo server")?
Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check
it. Both ispell and aspell have special modes for
checking debian/control files:
ispell -d american -g debian/control
aspell -d en -D -c debian/control
Users usually expect these questions to be answered in the package description:
What does the package do? If it is an add-on to another package, then the short description of the package we are an add-on to should be put in here.
Why should I want this package? This is related to the above, but not the same (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).
If this package should not be installed directly, but is pulled in by another package, this should be mentioned.
If the package is experimental, or there are other reasons it should not be used, if there are other packages that should be used instead, it should be here as well.
How is this package different from the competition? Is it a better implementation? more features? different features? Why should I choose this package.
We recommend that you add the URL for the package's home page in the
Homepage field of the Source section in
debian/control. Adding this information in the package
description itself is considered deprecated.
There are additional fields for the location of the Version Control System in
debian/control.
Value of this field should be a http:// URL pointing to a web-browsable copy of the Version Control System repository used to maintain the given package, if available.
The information is meant to be useful for the final user, willing to browse the latest work done on the package (e.g. when looking for the patch fixing a bug tagged as pending in the bug tracking system).
Value of this field should be a string identifying unequivocally the location of the Version Control System repository used to maintain the given package, if available. * identify the Version Control System; currently the following systems are supported by the package tracking system: arch, bzr (Bazaar), cvs, darcs, git, hg (Mercurial), mtn (Monotone), svn (Subversion). It is allowed to specify different VCS fields for the same package: they will all be shown in the PTS web interface.
The information is meant to be useful for a user knowledgeable in the given Version Control System and willing to build the current version of a package from the VCS sources. Other uses of this information might include automatic building of the latest VCS version of the given package. To this end the location pointed to by the field should better be version agnostic and point to the main branch (for VCSs supporting such a concept). Also, the location pointed to should be accessible to the final user; fulfilling this requirement might imply pointing to an anonymous access of the repository instead of pointing to an SSH-accessible version of the same.
In the following example, an instance of the field for a Subversion repository
of the vim package is shown. Note how the URL is in the
svn:// scheme (instead of svn+ssh://) and how it
points to the trunk/ branch. The use of the
Vcs-Browser and Homepage fields described above is
also shown.
Source: vim
Section: editors
Priority: optional
<snip>
Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
Homepage: http://www.vim.org
debian/changelog
The following practices supplement the Policy
on changelog files.
The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version.
Focus on what was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches).
There's no need to elaborate the trivial and obvious changes. You can also
aggregate several changes in one entry. On the other hand, don't be overly
terse if you have undertaken a major change. Be especially clear if there are
changes that affect the behaviour of the program. For further explanations,
use the README.Debian file.
Use common English so that the majority of readers can comprehend it. Avoid abbreviations, "tech-speak" and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear.
It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards.
When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the "closes: #nnnnn" string. See When bugs are closed by new uploads, Section 5.8.4 for more information.
The changelog entries should not document generic packaging issues ("Hey, if you're looking for foo.conf, it's in /etc/blah/."), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file.
The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See When bugs are closed by new uploads, Section 5.8.4.
The changelog entries should not be used for random discussion with bug reporters ("I don't see segfaults when starting foo with option bar; send in more info"), general statements on life, the universe and everything ("sorry this upload took me so long, but I caught the flu"), or pleas for help ("the bug list on this package is huge, please lend me a hand"). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See Responding to bugs, Section 5.8.2 for more information on how to use the bug tracking system.
It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload. As we have version tracking now, it is enough to keep the NMUed changelog entries and just mention this fact in your own changelog entry.
The following examples demonstrate some common errors or examples of bad style in changelog entries.
* Fixed all outstanding bugs.
This doesn't tell readers anything too useful, obviously.
* Applied patch from Jane Random.
What was the patch about?
* Late night install target overhaul.
Overhaul which accomplished what? Is the mention of late night supposed to remind us that we shouldn't trust that code?
* Fix vsync FU w/ ancient CRTs.
Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a curse word!) was actually about, or how it was fixed.
* This is not a bug, closes: #nnnnnn.
First of all, there's absolutely no need to upload the package to convey this information; instead, use the bug tracking system. Secondly, there's no explanation as to why the report is not a bug.
* Has been fixed for ages, but I forgot to close; closes: #54321.
If for some reason you didn't mention the bug number in a previous changelog entry, there's no problem, just close the bug normally in the BTS. There's no need to touch the changelog file, presuming the description of the fix is already in (this applies to the fixes by the upstream authors/maintainers as well, you don't have to track bugs that they fixed ages ago in your changelog).
* Closes: #12345, #12346, #15432
Where's the description? If you can't think of a descriptive message, start by inserting the title of each different bug.
Important news about changes in a package can also be put in NEWS.Debian files. The news will be displayed by tools like apt-listchanges, before all the rest of the changelogs. This is the preferred means to let the user know about significant changes in a package. It is better than using debconf notes since it is less annoying and the user can go back and refer to the NEWS.Debian file after the install. And it's better than listing major changes in README.Debian, since the user can easily miss such notes.
The file format is the same as a debian changelog file, but leave off the asterisks and describe each news item with a full paragraph when necessary rather than the more concise summaries that would go in a changelog. It's a good idea to run your file through dpkg-parsechangelog to check its formatting as it will not be automatically checked during build as the changelog is. Here is an example of a real NEWS.Debian file:
cron (3.0pl1-74) unstable; urgency=low
The checksecurity script is no longer included with the cron package:
it now has its own package, "checksecurity". If you liked the
functionality provided with that script, please install the new
package.
-- Steve Greenland <[email protected]> Sat, 6 Sep 2003 17:15:03 -0500
The NEWS.Debian file is installed as /usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and always has that name even in Debian native packages. If you use debhelper, dh_installchangelogs will install debian/NEWS files for you.
Unlike changelog files, you need not update NEWS.Debian files with every release. Only update them if you have something particularly newsworthy that user should know about. If you have no news at all, there's no need to ship a NEWS.Debian file in your package. No news is good news!
Maintainer scripts include the files debian/postinst,
debian/preinst, debian/prerm and
debian/postrm. These scripts take care of any package
installation or deinstallation setup which isn't handled merely by the creation
or removal of files and directories. The following instructions supplement the
Debian
Policy.
Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once.
Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty.
All prompting or interactive configuration should be kept to a minimum. When
it is necessary, you should use the debconf package for the
interface. Remember that prompting in any case can only be in the
configure stage of the postinst script.
Keep the maintainer scripts as simple as possible. We suggest you use pure
POSIX shell scripts. Remember, if you do need any bash features, the
maintainer script must have a bash shebang line. POSIX shell or Bash are
preferred to Perl, since they enable debhelper to easily add bits
to the scripts.
If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script.
If you need to check for the existence of a command, you should use something like
if [ -x /usr/sbin/install-docs ]; then ...
If you don't wish to hard-code the path of a command in your maintainer script, the following POSIX-compliant shell function may help:
pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
if [ -x "$p/$*" ]; then
IFS="$OLDIFS"
return 0
fi
done
IFS="$OLDIFS"
return 1
}
You can use this function to search $PATH for a command name,
passed as an argument. It returns true (zero) if the command was found, and
false if not. This is really the most portable way, since command
-v, type, and which are not POSIX.
While which is an acceptable alternative, since it is from the
required debianutils package, it's not on the root partition.
That is, it's in /usr/bin rather than /bin, so one
can't use it in scripts which are run before the /usr partition is
mounted. Most scripts won't have this problem, though.
debconf
Debconf is a configuration management system which can be used by
all the various packaging scripts (postinst mainly) to request
feedback from the user concerning how to configure the package. Direct user
interactions must now be avoided in favor of debconf interaction.
This will enable non-interactive installations in the future.
Debconf is a great tool but it is often poorly used. Many common mistakes are
listed in the debconf-devel(7) man page. It is something that you
must read if you decide to use debconf. Also, we document some best practices
here.
These guidelines include some writing style and typography recommendations, general considerations about debconf usage as well as more specific recommendations for some parts of the distribution (the installation system for instance).
Since debconf appeared in Debian, it has been widely abused and several criticisms received by the Debian distribution come from debconf abuse with the need of answering a wide bunch of questions before getting any little thing installed.
Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file. Only use notes for important notes which may directly affect the package usability. Remember that notes will always block the install until confirmed or bother the user by email.
Carefully choose the questions priorities in maintainer scripts. See
debconf-devel(7) for details about priorities. Most questions
should use medium and low priorities.
Most Debian package maintainers are not native English speakers. So, writing properly phrased templates may not be easy for them.
Please use (and abuse) [email protected]
mailing list. Have your templates proofread.
Badly written templates give a poor image of your package, of your work...or even of Debian itself.
Avoid technical jargon as much as possible. If some terms sound common to you, they may be impossible to understand for others. If you cannot avoid them, try to explain them (use the extended description). When doing so, try to balance between verbosity and simplicity.
Debconf templates may be translated. Debconf, along with its sister package
po-debconf offers a simple framework for getting templates
translated by translation teams or even individuals.
Please use gettext-based templates. Install po-debconf on your
development system and read its documentation ("man po-debconf" is a
good start).
Avoid changing templates too often. Changing templates text induces more work to translators which will get their translation "fuzzied". If you plan changes to your original templates, please contact translators. Most active translators are very responsive and getting their work included along with your modified templates will save you additional uploads. If you use gettext-based templates, the translator's name and e-mail addresses are mentioned in the po files headers.
The use of the podebconf-report-po from the po-debconf package is
highly recommended to warn translators which have incomplete translations and
request them for updates.
If in doubt, you may also contact the translation team for a given language
([email protected]), or the [email protected]
mailing list.
Calls for translations posted to [email protected]
with the debian/po/templates.pot file attached or referenced in a
URL are encouraged. Be sure to mentions in these calls for new translations
which languages you have existing translations for, in order to avoid duplicate
work.
When the text of a debconf template is corrected and you are sure that the change does not affect translations, please be kind to translators and unfuzzy their translations.
If you don't do so, the whole template will not be translated as long as a translator will send you an update.
To unfuzzy translations, you can proceed the following way:
Put all incomplete PO files out of the way. You can check the completeness by
using (needs the gettext package installed):
for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
--statistics $i; done
move all files which report either fuzzy strings to a temporary place. Files which report no fuzzy strings (only translated and untranslated) will be kept in place.
now and now only, modify the template for the typos and check again that translation are not impacted (typos, spelling errors, sometimes typographical corrections are usually OK)
run debconf-updatepo. This will fuzzy all strings you modified in
translations. You can see this by running the above again
use the following command:
for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done
move back to debian/po the files which showed fuzzy strings in the first step
run debconf-updatepo again
Templates text should not make reference to widgets belonging to some debconf interfaces. Sentences like "If you answer Yes..." have no meaning for users of graphical interfaces which use checkboxes for boolean questions.
String templates should also avoid mentioning the default values in their description. First, because this is redundant with the values seen by the users. Also, because these default values may be different from the maintainer choices (for instance, when the debconf database was preseeded).
More generally speaking, try to avoid referring to user actions. Just give facts.
You should avoid the use of first person ("I will do this..." or "We recommend..."). The computer is not a person and the Debconf templates do not speak for the Debian developers. You should use neutral construction. Those of you who already wrote scientific publications, just write your templates like you would write a scientific paper. However, try using action voice if still possible, like "Enable this if ..." instead of "This can be enabled if ...".
The world is made of men and women. Please use gender-neutral constructions in your writing.
This part gives some information which is mostly taken from the
debconf-devel(7) manual page.
Results in a free-form input field that the user can type any string into.
Prompts the user for a password. Use this with caution; be aware that the password the user enters will be written to debconf's database. You should probably clean that value out of the database as soon as is possible.
A true/false choice. Remember: true/false, not yes/no...
A choice between one of a number of values. The choices must be specified in a field named 'Choices'. Separate the possible values with commas and spaces, like this: Choices: yes, no, maybe
Like the select data type, except the user can choose any number of items from the choices list (or chose none of them).
Rather than being a question per se, this datatype indicates a note that can be displayed to the user. It should be used only for important notes that the user really should see, since debconf will go to great pains to make sure the user sees it; halting the install for them to press a key, and even mailing the note to them in some cases.
This type is now considered obsolete: don't use it.
This type is designed to handle error messages. It is mostly similar to the "note" type. Frontends may present it differently (for instance, the dialog frontend of cdebconf draws a red screen instead of the usual blue one).
It is recommended to use this type for any message that needs user attention for a correction of any kind.
Template descriptions have two parts: short and extended. The short description is in the "Description:" line of the template.
The short description should be kept short (50 characters or so) so that it may be accomodated by most debconf interfaces. Keeping it short also helps translators, as usually translations tend to end up being longer than the original.
The short description should be able to stand on its own. Some interfaces do not show the long description by default, or only if the user explicitely asks for it or even do not show it at all. Avoid things like "What do you want to do?"
The short description does not necessarily have to be a full sentence. This is part of the "keep it short and efficient" recommendation.
The extended description should not repeat the short description word for word. If you can't think up a long description, then first, think some more. Post to debian-devel. Ask for help. Take a writing class! That extended description is important. If after all that you still can't come up with anything, leave it blank.
The extended description should use complete sentences. Paragraphs should be kept short for improved readability. Do not mix two ideas in the same paragraph but rather use another paragraph.
Don't be too verbose. User tend to ignore too long screens. 20 lines are by experience a border you shouldn't cross, because that means that in the classical dialog interface, people will need to scroll, and lot of people just don't do that.
The extended description should never include a question.
For specific rules depending on templates type (string, boolean, etc.), please read below.
This field should be used for Select and Multiselect types. It contains the possible choices which will be presented to users. These choices should be separated by commas.
This field is optional. It contains the default answer for string, select and multiselect templates. For multiselect templates, it may contain a comma-separated list of choices.
No specific indication except: use the appropriate type by referring to the previous section.
Below are specific instructions for properly writing the Description (short and extended) depending on the template type.
The short description is a prompt and not a title. Avoid question style prompts ("IP Address?") in favour of "opened" prompts ("IP address:"). The use of colons is recommended.
The extended description is a complement to the short description. In the extended part, explain what is being asked, rather than ask the same question again using longer words. Use complete sentences. Terse writing style is strongly discouraged.
The short description should be phrased in the form of a question which should be kept short and should generally end with a question mark. Terse writing style is permitted and even encouraged if the question is rather long (remember that translations are often longer than original versions)
Again, please avoid referring to specific interface widgets. A common mistake for such templates is "if you answer Yes"-type constructions.
The short description is a prompt and not a title. Do not use useless "Please choose..." constructions. Users are clever enough to figure out they have to choose something...:)
The extended description will complete the short description. It may refer to the available choices. It may also mention that the user may choose more than one of the available choices, if the template is a multiselect one (although the interface often makes this clear).
The short description should be considered to be a *title*.
The extended description is what will be displayed as a more detailed explanation of the note. Phrases, no terse writing style.
Do not abuse debconf. Notes are the most common way to abuse debconf. As written in debconf-devel manual page: it's best to use them only for warning about very serious problems. The NEWS.Debian or README.Debian files are the appropriate location for a lot of notes. If, by reading this, you consider converting your Note type templates to entries in NEWS/Debian or README.Debian, plus consider keeping existing translations for the future.
If the Choices are likely to change often, please consider using the "__Choices" trick. This will split each individual choice into a single string, which will considerably help translators for doing their work.
If the default value, for a "select" template, is likely to vary depending on the user language (for instance, if the choice is a language choice), please use the "_DefaultChoice" trick.
This special field allow translators to put the most appropriate choice according to their own language. It will become the default choice when their language is used while your own mentioned Default Choice will be used chan using English.
Example, taken from the geneweb package templates:
Template: geneweb/lang
Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
# WARNING : you MUST use the ENGLISH FORM of your language
# For instance, the french translator will need to put "French (fr)" here.
_DefaultChoice: English (en)[ translators, please see comment in PO files]
_Description: Geneweb default language:
Note the use of brackets which allow internal comments in debconf fields. Also note the use of comments which will show up in files the translators will work with.
The comments are needed as the DefaultChoice trick is a bit confusing: the translators may put their own choice
Do NOT use empty default field. If you don't want to use default values, do not use Default at all.
If you use po-debconf (and you should, see 2.2), consider making this field translatable, if you think it may be translated.
If the default value may vary depending on language/country (for instance the
default value for a language choice), consider using the special
"_DefaultChoice" type documented in po-debconf(7)).
Like porters, translators have a difficult task. They work on many packages and must collaborate with many different maintainers. Moreover, most of the time, they are not native English speakers, so you may need to be particularly patient with them.
The goal of debconf was to make packages configuration easier for
maintainers and for users. Originally, translation of debconf templates was
handled with debconf-mergetemplate. However, that technique is
now deprecated; the best way to accomplish debconf
internationalization is by using the po-debconf package. This
method is easier both for maintainer and translators; transition scripts are
provided.
Using po-debconf, the translation is stored in po
files (drawing from gettext translation techniques). Special
template files contain the original messages and mark which fields are
translatable. When you change the value of a translatable field, by calling
debconf-updatepo, the translation is marked as needing attention
from the translators. Then, at build time, the dh_installdebconf
program takes care of all the needed magic to add the template along with the
up-to-date translations into the binary packages. Refer to the
po-debconf(7) manual page for details.
Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators.
If you maintain documentation of any size, its easier for translators if they
have access to a source control system. That lets translators see the
differences between two versions of the documentation, so, for instance, they
can see what needs to be retranslated. It is recommended that the translated
documentation maintain a note about what source control revision the
translation is based on. An interesting system is provided by doc-check
in the boot-floppies package, which shows an overview of the
translation status for any given language, using structured comments for the
current revision of the file to be translated and, for a translated file, the
revision of the original file the translation is based on. You might wish to
adapt and provide that in your CVS area.
If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file which is included by all the different translations. This makes it much easier, for instance, to keep URLs up to date across multiple files.
autoconf/automake
Keeping autoconf's config.sub and
config.guess files up to date is critical for porters, especially
on more volatile architectures. Some very good packaging practices for any
package using autoconf and/or automake have been
synthesized in /usr/share/doc/autotools-dev/README.Debian.gz from
the autotools-dev package. You're strongly encouraged to read
this file and to follow the given recommendations.
Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. Breakage in a library can result in dozens of dependent packages breaking.
Good practices for library packaging have been grouped in the library
packaging guide.
Be sure to follow the Policy on
documentation.
If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package.
Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and if output of reasonable quality is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML.
Major shipped manuals should register themselves with doc-base on
installation. See the doc-base package documentation for more
information.
Several specific types of packages have special sub-policies and corresponding packaging rules and practices:
Perl related packages have a Perl
policy, some examples of packages following that policy are
libdbd-pg-perl (binary perl module) or libmldbm-perl
(arch independent perl module).
Python related packages have their python policy; see
/usr/share/doc/python/python-policy.txt.gz in the
python package.
Emacs related packages have the emacs
policy.
Java related packages have their java
policy.
Ocaml related packages have their own policy, found in
/usr/share/doc/ocaml/ocaml_packaging_policy.gz from the
ocaml package. A good example is the camlzip source
package.
Packages providing XML or SGML DTDs should conform to the recommendations found
in the sgml-base-doc package.
Lisp packages should register themselves with
common-lisp-controller, about which see
/usr/share/doc/common-lisp-controller/README.packaging.
It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package.
However, if the size of the data is considerable, consider splitting it out
into a separate, architecture-independent package ("_all.deb"). By
doing this, you avoid needless duplication of the same data into eleven or more
.debs, one per each architecture. While this adds some extra overhead into the
Packages files, it saves a lot of disk space on Debian mirrors.
Separating out architecture-independent data also reduces processing time of
lintian or linda (see Package lint tools, Section A.2) when
run over the entire Debian archive.
If you need a certain locale during build, you can create a temporary file via this trick:
If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to the name of the locale you generate, you should get what you want without being root. Something like this:
LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8
mkdir -p $LOCALE_PATH
localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
# Using the locale
LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
Deborphan is a program for helping users to detect which packages can safely be removed from the system, i.e. the ones that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections, to hunt down unused libraries. But when passed the right argument, it tries to catch other useless packages.
For example, with --guess-dummy, deborphan tries to search all transitional packages which were needed for upgrade but which can now safely be removed. For that, it looks for the string "dummy" or "transitional" in their short description.
So, when you are creating such a package, please make sure to add this text to your short description. If you are looking for examples, just run:
apt-cache search .|grep dummy
or
apt-cache search .|grep transitional
.
orig.tar.gz filesThere are two kinds of original source tarballs: Pristine source and repackaged upstream source.
The defining characteristic of a pristine source tarball is that the .orig.tar.gz file is byte-for-byte identical to a tarball officially distributed by the upstream author. [5] This makes it possible to use checksums to easily verify that all changes between Debian's version and upstream's are contained in the Debian diff. Also, if the original source is huge, upstream authors and others who already have the upstream tarball can save download time if they want to inspect your packaging in detail.
There is no universally accepted guidelines that upstream authors follow
regarding to the directory structure inside their tarball, but
dpkg-source is nevertheless able to deal with most upstream
tarballs as pristine source. Its strategy is equivalent to the following:
It unpacks the tarball in an empty temporary directory by doing
zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
If, after this, the temporary directory contains nothing but one directory and
no other files, dpkg-source renames that directory to
<packagename>-<upstream-version>(.orig). The name of
the top-level directory in the tarball does not matter, and is forgotten.
Otherwise, the upstream tarball must have been packaged without a common
top-level directory (shame on the upstream author!). In this case,
dpkg-source renames the temporary directory itself to
<packagename>-<upstream-version>(.orig).
You should upload packages with a pristine source tarball if possible, but there are various reasons why it might not be possible. This is the case if upstream does not distribute the source as gzipped tar at all, or if upstream's tarball contains non-DFSG-free material that you must remove before uploading.
In these cases the developer must construct a suitable .orig.tar.gz file himself. We refer to such a tarball as a "repackaged upstream source". Note that a "repackaged upstream source" is different from a Debian-native package. A repackaged source still comes with Debian-specific changes in a separate .diff.gz and still has a version number composed of <upstream-version> and <debian-revision>.
There may be cases where it is desirable to repackage the source even though upstream distributes a .tar.gz that could in principle be used in its pristine form. The most obvious is if significant space savings can be achieved by recompressing the tar archive or by removing genuinely useless cruft from the upstream archive. Use your own discretion here, but be prepared to defend your decision if you repackage source that could have been pristine.
A repackaged .orig.tar.gz
must contain detailed information how the repackaged source
was obtained, and how this can be reproduced in the
debian/copyright. It is also a good idea to provide a
get-orig-source target in your debian/rules file that
repeats the process, as described in the Policy Manual, Main
building script: debian/rules.
should not contain any file that does not come from the upstream author(s), or whose contents has been changed by you. [6]
should, except where impossible for legal reasons, preserve
the entire building and portablility infrastructure provided by the upstream
author. For example, it is not a sufficient reason for omitting a file that it
is used only when building on MS-DOS. Similarly, a Makefile provided by
upstream should not be omitted even if the first thing your
debian/rules does is to overwrite it by running a configure
script.
(Rationale: It is common for Debian users who need to build software for non-Debian platforms to fetch the source from a Debian mirror rather than trying to locate a canonical upstream distribution point).
should use <packagename>-<upstream-version>.orig as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones.
should be gzipped with maximal compression.
The canonical way to meet the latter two points is to let dpkg-source -b construct the repackaged tarball from an unpacked directory.
Sometimes it is necessary to change binary files contained in the original
tarball, or to add binary files that are not in it. If this is done by simply
copying the files into the debianized source tree, dpkg-source
will not be able to handle this. On the other hand, according to the
guidelines given above, you cannot include such a changed binary file in a
repackaged orig.tar.gz. Instead, include the file in the
debian directory in uuencoded (or similar) form [7]. The file would then be decoded
and copied to its place during the build process. Thus the change will be
visible quite easy.
Some packages use dbs to manage patches to their upstream source,
and always create a new orig.tar.gz file that contains the real
orig.tar.gz in its toplevel directory. This is questionable with
respect to the preference for pristine source. On the other hand, it is easy
to modify or add binary files in this case: Just put them into the newly
created orig.tar.gz file, besides the real one, and copy them to
the right place during the build process.
A debug package is a package with a name ending in "-dbg", that contains additional information that gdb can use. Since Debian binaries are stripped by default, debugging information, including function names and line numbers, is otherwise not available when running gdb on Debian binaries. Debug packages allow users who need this additional debugging information to install it, without bloating a regular system with the information.
It is up to a package's maintainer whether to create a debug package or not. Maintainers are encouraged to create debug packages for library packages, since this can aid in debugging many programs linked to a library. In general, debug packages do not need to be added for all programs; doing so would bloat the archive. But if a maintainer finds that users often need a debugging version of a program, it can be worthwhile to make a debug package for it. Programs that are core infrastructure, such as apache and the X server are also good candidates for debug packages.
Some debug packages may contain an entire special debugging build of a library
or other binary, but most of them can save space and build time by instead
containing separated debugging symbols that gdb can find and load on the fly
when debugging a program or library. The convention in Debian is to keep these
symbols in /usr/lib/debug/path, where path is
the path to the executable or library. For example, debugging symbols for
/usr/bin/foo go in /usr/lib/debug/usr/bin/foo, and
debugging symbols for /usr/lib/libfoo.so.1 go in
/usr/lib/debug/usr/lib/libfoo.so.1.
The debugging symbols can be extracted from an object file using "objcopy
--only-keep-debug". Then the object file can be stripped, and
"objcopy --add-gnu-debuglink" used to specify the path to the
debugging symbol file. objcopy(1) explains in detail how this
works.
The dh_strip command in debhelper supports creating debug packages, and can take care of using objcopy to separate out the debugging symbols for you. If your package uses debhelper, all you need to do is call "dh_strip --dbg-package=libfoo-dbg", and add an entry to debian/control for the debug package.
Note that the Debian package should depend on the package that it provides debugging symbols for, and this dependency should be versioned. For example:
Depends: libfoo-dbg (= ${binary:Version})
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]
Debian Developer's Reference
[email protected]