Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
deb-src-control(5)		  dpkg suite		    deb-src-control(5)

       deb-src-control - Debian	source packages' master	control	file format


       Each  Debian source package contains the	master <<control>> file, which
       contains	at least 2 paragraphs, separated by a blank line.   The	 first
       paragraph  lists	 all  information about	the source package in general,
       while each following paragraph describes	exactly	 one  binary  package.
       Each  paragraph	consists  of at	least one field. A field starts	with a
       fieldname, such as Package or Section (case insensitive), followed by a
       colon, the body of the field and	a newline.  Multi-line fields are also
       allowed,	but each supplementary line, without a fieldname, should start
       with  at	 least	one  space.  The  content  of the multi-line fields is
       generally joined	to a single line by the	tools (except in the  case  of
       the  Description	field, see below). To insert empty lines into a	multi-
       line field, insert a dot	after the space.  Lines	starting  with	a  `#'
       are treated as comments.

       Source: source-package-name (required)
	      The  value  of this field	is the name of the source package, and
	      should  match  the  name	of   the   source   package   in   the
	      debian/changelog	file.  A  package  name	 must  consist only of
	      lowercase	letters	(a-z), digits (0-9), plus (+)  and  minus  (-)
	      signs,  and  periods  (.).  Package  names  must be at least two
	      characters long and must start  with  a  lowercase  alphanumeric
	      character	(a-z0-9).

       Maintainer: fullname-email (recommended)
	      Should  be  in  the format <<Joe Bloggs <>>>, and
	      references the person who	currently maintains  the  package,  as
	      opposed to the author of the software or the original packager.

       Uploaders: fullname-email
	      Lists all	the names and email addresses of co-maintainers	of the
	      package, in the same format as the Maintainer  field.   Multiple
	      co-maintainers should be separated by a comma.

       Standards-Version: version-string
	      This  documents  the  most  recent  version  of the distribution
	      policy standards this package complies with.

       Description short-description
	      The format for the source	package	description is a  short	 brief
	      summary  on  the	first line (after the Description field).  The
	      following	lines should  be  used	as  a  longer,	more  detailed
	      description.  Each line of the long description must be preceded
	      by a space, and blank lines in the long description must contain
	      a	single `.' following the preceding space.

       Homepage: url
	      The upstream project home	page URL.

       Bugs: url
	      The url of the bug tracking system for this package. The current
	      used	format	    is	    bts-type://bts-address,	  like
	      debbugs:// This field is usually not needed.

       Rules-Requires-Root: no|binary-targets|impl-keywords
	      This  field  is  used  to	indicate whether the debian/rules file
	      requires (fake)root privileges to	run some of its	 targets,  and
	      if so when.

	      no     The binary	targets	will not require (fake)root at all.

		     The  binary  targets must always be run under (fake)root.
		     This value	is the default	when  the  field  is  omitted;
		     adding  the  field	 with an explicit binary-targets while
		     not strictly needed, marks	it as having been analyzed for
		     this requirement.

		     This  is  a space-separated list of keywords which	define
		     when (fake)root is	required.

		     Keywords consist of namespace/cases.  The namespace  part
		     cannot  contain "/" or whitespace.	 The cases part	cannot
		     contain whitespace.  Furthermore, both parts must consist
		     entirely of printable ASCII characters.

		     Each  tool/package	 will  define  a namespace named after
		     itself and	provide	a number of cases where	(fake)root  is
		     required.	 (See  "Implementation	provided  keywords" in

		     When the field is set to one of  the  impl-keywords,  the
		     builder  will  expose  an interface that is used to run a
		     command  under  (fake)root.   (See	 "Gain	Root  API"  in

       Testsuite: name-list
       Testsuite-Triggers: package-list
	      These  fields  are  described in the dsc(5) manual page, as they
	      are     generated	    from     information     inferred	  from
	      debian/tests/control  or	copied literally to the	source control

       Vcs-Arch: url
       Vcs-Bzr:	url
       Vcs-Cvs:	url
       Vcs-Darcs: url
       Vcs-Git:	url
       Vcs-Hg: url
       Vcs-Mtn:	url
       Vcs-Svn:	url
	      The url  of  the	Version	 Control  System  repository  used  to
	      maintain	 this  package.	 Currently  supported  are  Arch,  Bzr
	      (Bazaar),	Cvs, Darcs, Git, Hg (Mercurial),  Mtn  (Monotone)  and
	      Svn  (Subversion).  Usually  this	 field	points	to  the	latest
	      version of the package, such as the main branch or the trunk.

       Vcs-Browser: url
	      The url of a webinterface	to browse the Version  Control	System

       Origin: name
	      The  name	 of the	distribution this package is originating from.
	      This field is usually not	needed.

       Section:	section
	      This is a	general	field that gives the package a category	 based
	      on  the  software	 that  it  installs.  Some common sections are
	      utils, net, mail,	text, x11, etc.

       Priority: priority
	      Sets the importance of this package in relation to the system as
	      a	 whole.	  Common  priorities are required, standard, optional,
	      extra, etc.

	      The Section and Priority fields usually have a  defined  set  of
	      accepted values based on the specific distribution policy.

       Build-Depends: package-list
	      A	 list  of packages that	need to	be installed and configured to
	      be able to build from source package.  These  dependencies  need
	      to  be  satisfied	when building binary architecture dependent or
	      independent  packages  and   source   packages.	 Including   a
	      dependency  in this field	does not have the exact	same effect as
	      including	it in both Build-Depends-Arch and Build-Depends-Indep,
	      because  the dependency also needs to be satisfied when building
	      the source package.

       Build-Depends-Arch: package-list
	      Same as Build-Depends, but they are only	needed	when  building
	      the  architecture	dependent packages. The	Build-Depends are also
	      installed	in this	case.  This  field  is	supported  since  dpkg
	      1.16.4;	in   order   to	  build	  with	older  dpkg  versions,
	      Build-Depends should be used instead.

       Build-Depends-Indep: package-list
	      Same as Build-Depends, but they are only	needed	when  building
	      the  architecture	 independent  packages.	 The Build-Depends are
	      also installed in	this case.

       Build-Conflicts:	package-list
	      A	list of	packages that should not be installed when the package
	      is  built,  for  example	because	 they interfere	with the build
	      system used.  Including a	dependency in this list	has  the  same
	      effect   as   including  it  in  both  Build-Conflicts-Arch  and
	      Build-Conflicts-Indep, with the additional effect	of being  used
	      for source-only builds.

       Build-Conflicts-Arch: package-list
	      Same as Build-Conflicts, but only	when building the architecture
	      dependent	packages. This field is	supported since	 dpkg  1.16.4;
	      in  order	 to  build  with  older	dpkg versions, Build-Conflicts
	      should be	used instead.

       Build-Conflicts-Indep: package-list
	      Same as Build-Conflicts, but only	when building the architecture
	      independent packages.

       The    syntax	of    the    Build-Depends,   Build-Depends-Arch   and
       Build-Depends-Indep fields is a list of groups of alternative packages.
       Each  group is a	list of	packages separated by vertical bar (or "pipe")
       symbols,	`|'.  The groups are separated by commas `,', and can end with
       a trailing comma	that will be eliminated	when generating	the fields for
       deb-control(5) (since dpkg 1.10.14).  Commas are	to be read  as	"AND",
       and  pipes as "OR", with	pipes binding more tightly.  Each package name
       is optionally followed by an architecture qualifier  appended  after  a
       colon  `:',  optionally	followed  by a version number specification in
       parentheses `('	and  `)',  an  architecture  specification  in	square
       brackets	 `['  and  `]',	and a restriction formula consisting of	one or
       more lists of profile names in angle brackets `<' and `>'.

       The   syntax   of   the	 Build-Conflicts,   Build-Conflicts-Arch   and
       Build-Conflicts-Indep  fields  is  a  list  of  comma-separated package
       names, where the	comma is read as an "AND", and where the list can  end
       with  a	trailing  comma	 that  will  be	eliminated when	generating the
       fields for deb-control(5) (since	dpkg 1.10.14).	Specifying alternative
       packages	 using	a  "pipe"  is  not  supported.	 Each  package name is
       optionally followed by a	version	number specification  in  parentheses,
       an  architecture	 specification	in  square brackets, and a restriction
       formula consisting of one or more  lists	 of  profile  names  in	 angle

       An  architecture	 qualifier name	can be a real Debian architecture name
       (since dpkg 1.16.5), any	(since dpkg  1.16.2)  or  native  (since  dpkg
       1.16.5).	  If  omitted,	the  default  for  Build-Depends fields	is the
       current host architecture, the default for  Build-Conflicts  fields  is
       any.    A  real	Debian	architecture  name  will  match	 exactly  that
       architecture for	that package name, any will match any architecture for
       that  package  name  if the package is marked with Multi-Arch: allowed,
       and native will match the current build architecture if the package  is
       not marked with Multi-Arch: foreign.

       A version number	may start with a `>>', in which	case any later version
       will match, and may specify  or	omit  the  Debian  packaging  revision
       (separated  by  a hyphen).  Accepted version relationships are `>>' for
       greater than, `<<' for less than, `>=' for greater than	or  equal  to,
       `<=' for	less than or equal to, and `=' for equal to.

       An  architecture	 specification	consists  of  one or more architecture
       names, separated	by whitespace. Exclamation marks may be	 prepended  to
       each of the names, meaning "NOT".

       A  restriction  formula	consists  of  one  or  more restriction	lists,
       separated by whitespace.	Each restriction list  is  enclosed  in	 angle
       brackets.  Items	 in  the  restriction  list  are  build	profile	names,
       separated by whitespace and can be prefixed with	an  exclamation	 mark,
       meaning	"NOT".	 A restriction formula represents a disjunctive	normal
       form expression.

       Note that dependencies on packages in the build-essential  set  can  be
       omitted	and that declaring build conflicts against them	is impossible.
       A list of these packages	is in the build-essential package.

       Note that the Priority, Section and Homepage fields can also  be	 in  a
       binary paragraph	to override the	global value from the source package.

       Package:	binary-package-name (required)
	      This  field  is  used  to	name the binary	package	name. The same
	      restrictions as to a source package name apply.

       Package-Type: deb|udeb|type
	      This field defines the type of the package.  udeb	is  for	 size-
	      constrained  packages  used by the debian	installer.  deb	is the
	      default value, it	is assumed if the field	is absent.  More types
	      might be added in	the future.

       Architecture: arch|all|any (required)
	      The  architecture	 specifies  on	which  type  of	 hardware this
	      package runs. For	packages that run on  all  architectures,  use
	      the  any	value. For packages that are architecture independent,
	      such as shell and	Perl scripts or	 documentation,	 use  the  all
	      value.   To   restrict   the   packages  to  a  certain  set  of
	      architectures, specify the architecture names,  separated	 by  a
	      space.  It's also	possible to put	architecture wildcards in that
	      list (see	dpkg-architecture(1) for more information about	them).

       Build-Profiles: restriction-formula
	      This field  specifies  the  conditions  for  which  this	binary
	      package  does or does not	build.	To express that	condition, the
	      same restriction formula syntax from the Build-Depends field  is

	      If  a binary package paragraph does not contain this field, then
	      it implicitly means that	it  builds  with  all  build  profiles
	      (including none at all).

	      In  other	words, if a binary package paragraph is	annotated with
	      a	non-empty Build-Profiles field,	then this  binary  package  is
	      generated	 if  and  only	if  the	 condition  expressed  by  the
	      conjunctive normal form expression evaluates to true.

       Essential: yes|no
       Build-Essential:	yes|no
       Multi-Arch: same|foreign|allowed|no
       Tag: tag-list
       Description: short-description (recommended)
	      These fields are described in the	deb-control(5) manual page, as
	      they  are	 copied	 literally  to	the control file of the	binary

       Depends:	package-list
       Pre-Depends: package-list
       Recommends: package-list
       Suggests: package-list
       Breaks: package-list
       Enhances: package-list
       Replaces: package-list
       Conflicts: package-list
       Provides: package-list
       Built-Using: package-list
	      These fields declare relationships between  packages.  They  are
	      discussed	 in the	deb-control(5) manpage.	 When these fields are
	      found in debian/control they can also end	with a trailing	 comma
	      (since  dpkg  1.10.14),  have  architecture  specifications  and
	      restriction formulas which will all get reduced when  generating
	      the fields for deb-control(5).

       Subarchitecture:	value
       Kernel-Version: value
       Installer-Menu-Item: value
	      These  fields  are used by the debian-installer in udebs and are
	      usually		   not		    needed.		   See
	      /usr/share/doc/debian-installer/devel/modules.txt	   from	   the
	      debian-installer package for more	details	about them.

       It is allowed to	add additional	user-defined  fields  to  the  control
       file.  The tools	will ignore these fields. If you want the fields to be
       copied over to the output files,	such as	the binary packages, you  need
       to  use	a  custom  naming  scheme:  the	fields should start with an X,
       followed	by zero	or more	of the letters SBC and a hyphen.

       S      The field	will appear in the source package  control  file,  see

       B      The field	will appear in the control file	in the binary package,
	      see deb-control(5).

       C      The field	will appear in the upload control (.changes) file, see

       Note  that the X[SBC]- prefixes are stripped when the fields are	copied
       over to the  output  files.  A  field  XC-Approved-By  will  appear  as
       Approved-By  in	the  changes file and will not appear in the binary or
       source package control files.

       Take into account that these user-defined  fields  will	be  using  the
       global  namespace, which	might at some point in the future collide with
       officially recognized fields. To	avoid such potential situation you can
       prefix those fields with	Private-, such as XB-Private-New-Field.

       # Comment
       Source: dpkg
       Section:	admin
       Priority: required
       Maintainer: Dpkg	Developers <>
       # this field is copied to the binary and	source packages
       XBS-Upstream-Release-Status: stable
       Standards-Version: 3.7.3
       Build-Depends: pkg-config, debhelper (>=	4.1.81),
	libselinux1-dev	(>= 1.28-4) [!linux-any]

       Package:	dpkg-dev
       Section:	utils
       Priority: optional
       Architecture: all
       # this is a custom field	in the binary package
       XB-Mentoring-Contact: Raphael Hertzog <>
       Depends:	dpkg (>= 1.14.6), perl5, perl-modules, cpio (>=	2.4.2-2),
	bzip2, lzma, patch (>= 2.2-1), make, binutils, libtimedate-perl
       Recommends: gcc | c-compiler, build-essential
       Suggests: gnupg,	debian-keyring
       Conflicts: dpkg-cross (<< 2.0.0), devscripts (<<	2.10.26)
       Replaces: manpages-pl (<= 20051117-1)
       Description: Debian package development tools
	This package provides the development tools (including dpkg-source)
	required to unpack, build and upload Debian source packages.
	Most Debian source packages will require additional tools to build;
	for example, most packages need	make and the C compiler	gcc.

       deb-control(5), deb-version(7), dpkg-source(1)

1.19.7				  2019-06-03		    deb-src-control(5)


Want to link to this manual page? Use this URL:

home | help