│ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ -

7. Diversions - overriding a package's version of a file (from old Packaging Manual)

│ │ │ │ +

7. Diversions - overriding a package’s version of a file (from old Packaging Manual)

│ │ │ │

It is possible to have dpkg not overwrite a file when it reinstalls │ │ │ │ the package it belongs to, and to have it put the file from the package │ │ │ │ somewhere else instead.

│ │ │ │ -

This can be used locally to override a package's version of a file, or │ │ │ │ -by one package to override another's version (or provide a wrapper for │ │ │ │ +

This can be used locally to override a package’s version of a file, or │ │ │ │ +by one package to override another’s version (or provide a wrapper for │ │ │ │ it).

│ │ │ │

Before deciding to use a diversion, read │ │ │ │ Alternative versions of an interface - update-alternatives (from old Packaging Manual) to see if you really want a │ │ │ │ diversion rather than several alternative versions of a program.

│ │ │ │

There is a diversion list, which is read by dpkg, and updated by a │ │ │ │ special program dpkg-divert. Please see dpkg-divert(8) for │ │ │ │ full details of its operation.

│ │ │ │ @@ -117,17 +117,17 @@ │ │ │ │ dpkg-divert in its preinst to add the diversion and rename the │ │ │ │ existing file. For example, supposing that a smailwrapper package │ │ │ │ wishes to install a wrapper around /usr/sbin/smail:

│ │ │ │ 
dpkg-divert --package smailwrapper --add --rename \
│ │ │ │      --divert /usr/sbin/smail.real /usr/sbin/smail
│ │ │ │
│ │ │ │
│ │ │ │ -

The --package smailwrapper ensures that smailwrapper's copy of │ │ │ │ +

The --package smailwrapper ensures that smailwrapper’s copy of │ │ │ │ /usr/sbin/smail can bypass the diversion and get installed as the │ │ │ │ -true version. It's safe to add the diversion unconditionally on upgrades │ │ │ │ +true version. It’s safe to add the diversion unconditionally on upgrades │ │ │ │ since it will be left unchanged if it already exists, but │ │ │ │ dpkg-divert will display a message. To suppress that message, make │ │ │ │ the command conditional on the version from which the package is being │ │ │ │ upgraded:

│ │ │ │ 
if [ upgrade != "$1" ] || dpkg --compare-versions "$2" lt 1.0-2; then
│ │ │ │      dpkg-divert --package smailwrapper --add --rename \
│ │ │ │          --divert /usr/sbin/smail.real /usr/sbin/smail
│ │ │ │ @@ -152,19 +152,19 @@
│ │ │ │      dpkg-divert --package smailwrapper --remove --rename \
│ │ │ │          --divert /usr/sbin/smail.real /usr/sbin/smail
│ │ │ │  fi
│ │ │ │
│ │ │ │
│ │ │ │

where 1.0-2 is the version at which the diversion was first added to │ │ │ │ the package. The postrm should not remove the diversion on upgrades both │ │ │ │ -because there's no reason to remove the diversion only to immediately │ │ │ │ +because there’s no reason to remove the diversion only to immediately │ │ │ │ re-add it and since the postrm of the old package is run after unpacking │ │ │ │ so the removal of the diversion will fail.

│ │ │ │

Do not attempt to divert a file which is vitally important for the │ │ │ │ -system's operation - when using dpkg-divert there is a time, after │ │ │ │ +system’s operation - when using dpkg-divert there is a time, after │ │ │ │ it has been diverted but before dpkg has installed the new version, │ │ │ │ when the file does not exist.

│ │ │ │

Do not attempt to divert a conffile, as dpkg does not handle it │ │ │ │ well.

│ │ │ │

Do not use diversions for files that have their own native override mechanisms, │ │ │ │ such as systemd unit files. See Binary packages for more information.

│ │ │ │
│ │ │ │ ├── html2text {} │ │ │ │ │ @@ -28,35 +28,35 @@ │ │ │ │ │ * _1_1_._ _L_i_c_e_n_s_e │ │ │ │ │ _D_e_b_i_a_n_ _P_o_l_i_c_y_ _M_a_n_u_a_l │ │ │ │ │ * 7. Diversions - overriding a package’s version of a file (from old │ │ │ │ │ Packaging Manual) │ │ │ │ │ * _V_i_e_w_ _p_a_g_e_ _s_o_u_r_c_e │ │ │ │ │ _P_r_e_v_i_o_u_s _N_e_x_t │ │ │ │ │ =============================================================================== │ │ │ │ │ -************ 77.. DDiivveerrssiioonnss -- oovveerrrriiddiinngg aa ppaacckkaaggee''ss vveerrssiioonn ooff aa ffiillee ((ffrroomm oolldd │ │ │ │ │ +************ 77.. DDiivveerrssiioonnss -- oovveerrrriiddiinngg aa ppaacckkaaggee?’ss vveerrssiioonn ooff aa ffiillee ((ffrroomm oolldd │ │ │ │ │ PPaacckkaaggiinngg MMaannuuaall))_? ************ │ │ │ │ │ It is possible to have dpkg not overwrite a file when it reinstalls the package │ │ │ │ │ it belongs to, and to have it put the file from the package somewhere else │ │ │ │ │ instead. │ │ │ │ │ -This can be used locally to override a package's version of a file, or by one │ │ │ │ │ -package to override another's version (or provide a wrapper for it). │ │ │ │ │ +This can be used locally to override a package’s version of a file, or by one │ │ │ │ │ +package to override another’s version (or provide a wrapper for it). │ │ │ │ │ Before deciding to use a diversion, read _A_l_t_e_r_n_a_t_i_v_e_ _v_e_r_s_i_o_n_s_ _o_f_ _a_n_ _i_n_t_e_r_f_a_c_e_ _- │ │ │ │ │ _u_p_d_a_t_e_-_a_l_t_e_r_n_a_t_i_v_e_s_ _(_f_r_o_m_ _o_l_d_ _P_a_c_k_a_g_i_n_g_ _M_a_n_u_a_l_) to see if you really want a │ │ │ │ │ diversion rather than several alternative versions of a program. │ │ │ │ │ There is a diversion list, which is read by dpkg, and updated by a special │ │ │ │ │ program dpkg-divert. Please see ddppkkgg--ddiivveerrtt((88)) for full details of its │ │ │ │ │ operation. │ │ │ │ │ When a package wishes to divert a file from another, it should call dpkg-divert │ │ │ │ │ in its preinst to add the diversion and rename the existing file. For example, │ │ │ │ │ supposing that a smailwrapper package wishes to install a wrapper around /usr/ │ │ │ │ │ sbin/smail: │ │ │ │ │ dpkg-divert --package smailwrapper --add --rename \ │ │ │ │ │ --divert /usr/sbin/smail.real /usr/sbin/smail │ │ │ │ │ -The --package smailwrapper ensures that smailwrapper's copy of /usr/sbin/smail │ │ │ │ │ -can bypass the diversion and get installed as the true version. It's safe to │ │ │ │ │ +The --package smailwrapper ensures that smailwrapper’s copy of /usr/sbin/smail │ │ │ │ │ +can bypass the diversion and get installed as the true version. It’s safe to │ │ │ │ │ add the diversion unconditionally on upgrades since it will be left unchanged │ │ │ │ │ if it already exists, but dpkg-divert will display a message. To suppress that │ │ │ │ │ message, make the command conditional on the version from which the package is │ │ │ │ │ being upgraded: │ │ │ │ │ if [ upgrade != "$1" ] || dpkg --compare-versions "$2" lt 1.0-2; then │ │ │ │ │ dpkg-divert --package smailwrapper --add --rename \ │ │ │ │ │ --divert /usr/sbin/smail.real /usr/sbin/smail │ │ │ │ │ @@ -73,18 +73,18 @@ │ │ │ │ │ version is so old that direct upgrades are no longer supported): │ │ │ │ │ if [ abort-upgrade = "$1" ] && dpkg --compare-versions "$2" lt 1.0-2; then │ │ │ │ │ dpkg-divert --package smailwrapper --remove --rename \ │ │ │ │ │ --divert /usr/sbin/smail.real /usr/sbin/smail │ │ │ │ │ fi │ │ │ │ │ where 1.0-2 is the version at which the diversion was first added to the │ │ │ │ │ package. The postrm should not remove the diversion on upgrades both because │ │ │ │ │ -there's no reason to remove the diversion only to immediately re-add it and │ │ │ │ │ +there’s no reason to remove the diversion only to immediately re-add it and │ │ │ │ │ since the postrm of the old package is run after unpacking so the removal of │ │ │ │ │ the diversion will fail. │ │ │ │ │ -Do not attempt to divert a file which is vitally important for the system's │ │ │ │ │ +Do not attempt to divert a file which is vitally important for the system’s │ │ │ │ │ operation - when using dpkg-divert there is a time, after it has been diverted │ │ │ │ │ but before dpkg has installed the new version, when the file does not exist. │ │ │ │ │ Do not attempt to divert a conffile, as dpkg does not handle it well. │ │ │ │ │ Do not use diversions for files that have their own native override mechanisms, │ │ │ │ │ such as systemd unit files. See _B_i_n_a_r_y_ _p_a_c_k_a_g_e_s for more information. │ │ │ │ │ _P_r_e_v_i_o_u_s _N_e_x_t │ │ │ │ │ =============================================================================== │ │ │ ├── ./usr/share/doc/debian-policy/policy.html/ap-pkg-scope.html │ │ │ │ @@ -128,24 +128,24 @@ │ │ │ │ of some packages.

│ │ │ │

This manual describes the technical aspects of creating Debian binary │ │ │ │ packages (.deb files). It documents the behavior of the package │ │ │ │ management programs dpkg, dselect et al. and the way they │ │ │ │ interact with packages.

│ │ │ │

This manual does not go into detail about the options and usage of the │ │ │ │ package building and installation tools. It should therefore be read in │ │ │ │ -conjunction with those programs' man pages.

│ │ │ │ +conjunction with those programs’ man pages.

│ │ │ │

The utility programs which are provided with dpkg not described in │ │ │ │ detail here, are documented in their man pages.

│ │ │ │

It is assumed that the reader is reasonably familiar with the dpkg │ │ │ │ -System Administrators' manual. Unfortunately this manual does not yet │ │ │ │ +System Administrators’ manual. Unfortunately this manual does not yet │ │ │ │ exist.

│ │ │ │ -

The Debian version of the FSF's GNU hello program is provided as an │ │ │ │ +

The Debian version of the FSF’s GNU hello program is provided as an │ │ │ │ example for people wishing to create Debian packages. However, while the │ │ │ │ examples are helpful, they do not replace the need to read and follow │ │ │ │ -the Policy and Programmer's Manual.

│ │ │ │ +the Policy and Programmer’s Manual.

│ │ │ │ │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -55,21 +55,21 @@ │ │ │ │ │ programs (usually compiled binaries) and their associated data, though source │ │ │ │ │ code examples and documentation are provided as part of some packages. │ │ │ │ │ This manual describes the technical aspects of creating Debian binary packages │ │ │ │ │ (.deb files). It documents the behavior of the package management programs │ │ │ │ │ dpkg, dselect et al. and the way they interact with packages. │ │ │ │ │ This manual does not go into detail about the options and usage of the package │ │ │ │ │ building and installation tools. It should therefore be read in conjunction │ │ │ │ │ -with those programs' man pages. │ │ │ │ │ +with those programs’ man pages. │ │ │ │ │ The utility programs which are provided with dpkg not described in detail here, │ │ │ │ │ are documented in their man pages. │ │ │ │ │ It is assumed that the reader is reasonably familiar with the dpkg System │ │ │ │ │ -Administrators' manual. Unfortunately this manual does not yet exist. │ │ │ │ │ -The Debian version of the FSF's GNU hello program is provided as an example for │ │ │ │ │ +Administrators’ manual. Unfortunately this manual does not yet exist. │ │ │ │ │ +The Debian version of the FSF’s GNU hello program is provided as an example for │ │ │ │ │ people wishing to create Debian packages. However, while the examples are │ │ │ │ │ helpful, they do not replace the need to read and follow the Policy and │ │ │ │ │ -Programmer's Manual. │ │ │ │ │ +Programmer’s Manual. │ │ │ │ │ [_1] │ │ │ │ │ dpkg is targeted primarily at Debian, but may work on or be ported to other │ │ │ │ │ systems. │ │ │ │ │ _P_r_e_v_i_o_u_s _N_e_x_t │ │ │ │ │ =============================================================================== │ │ │ ├── ./usr/share/doc/debian-policy/policy.html/ap-pkg-sourcepkg.html │ │ │ │ @@ -184,27 +184,27 @@ │ │ │ │ it in debian/tmp relative to the top of the source package, it is │ │ │ │ usually sufficient to call dpkg-gencontrol.

│ │ │ │

Sources which build several binaries will typically need something like:

│ │ │ │ 
dpkg-gencontrol -Pdebian/pkg -ppackage
│ │ │ │
│ │ │ │
│ │ │ │

The -P tells dpkg-gencontrol that the package is being built in │ │ │ │ -a non-default directory, and the -p tells it which binary package's │ │ │ │ +a non-default directory, and the -p tells it which binary package’s │ │ │ │ control file should be generated.

│ │ │ │

dpkg-gencontrol also adds information to the list of files in │ │ │ │ debian/files, for the benefit of (for example) a future invocation │ │ │ │ of dpkg-genchanges.

│ │ │ │ │ │ │ │
│ │ │ │

3.1.4. dpkg-shlibdeps - calculates shared library dependencies

│ │ │ │

See dpkg-shlibdeps(1).

│ │ │ │
│ │ │ │
│ │ │ │

3.1.5. dpkg-distaddfile - adds a file to debian/files

│ │ │ │ -

Some packages' uploads need to include files other than the source and │ │ │ │ +

Some packages’ uploads need to include files other than the source and │ │ │ │ binary package files.

│ │ │ │

dpkg-distaddfile adds a file to the debian/files file so that it │ │ │ │ will be included in the .changes file when dpkg-genchanges is │ │ │ │ run.

│ │ │ │

It is usually invoked from the binary target of debian/rules:

│ │ │ │ 
dpkg-distaddfile filename section priority
│ │ │ │
│ │ │ │ @@ -253,15 +253,15 @@ │ │ │ │

See Generated files list: debian/files.

│ │ │ │
│ │ │ │
│ │ │ │

3.2.4. debian/tmp

│ │ │ │

This is the default temporary location for the construction of binary │ │ │ │ packages by the binary target. The directory tmp serves as the │ │ │ │ root of the file system tree as it is being constructed (for example, by │ │ │ │ -using the package's upstream makefiles install targets and redirecting │ │ │ │ +using the package’s upstream makefiles install targets and redirecting │ │ │ │ the output there), and it also contains the DEBIAN subdirectory. See │ │ │ │ Creating package files - dpkg-deb.

│ │ │ │

This is only a default and can be easily overridden. Most packaging │ │ │ │ tools no longer use debian/tmp, instead preferring debian/pkg │ │ │ │ for the common case of a source package building only one binary │ │ │ │ package. Such tools usually only use debian/tmp as a temporary │ │ │ │ staging area for built files and do not construct packages from it.

│ │ │ │ ├── html2text {} │ │ │ │ │ @@ -97,22 +97,22 @@ │ │ │ │ │ available. │ │ │ │ │ For a package which generates only one binary package, and which builds it in │ │ │ │ │ debian/tmp relative to the top of the source package, it is usually sufficient │ │ │ │ │ to call dpkg-gencontrol. │ │ │ │ │ Sources which build several binaries will typically need something like: │ │ │ │ │ dpkg-gencontrol -Pdebian/pkg -ppackage │ │ │ │ │ The -P tells dpkg-gencontrol that the package is being built in a non-default │ │ │ │ │ -directory, and the -p tells it which binary package's control file should be │ │ │ │ │ +directory, and the -p tells it which binary package’s control file should be │ │ │ │ │ generated. │ │ │ │ │ dpkg-gencontrol also adds information to the list of files in debian/files, for │ │ │ │ │ the benefit of (for example) a future invocation of dpkg-genchanges. │ │ │ │ │ ******** 33..11..44.. ddppkkgg--sshhlliibbddeeppss -- ccaallccuullaatteess sshhaarreedd lliibbrraarryy ddeeppeennddeenncciieess_? ******** │ │ │ │ │ See ddppkkgg--sshhlliibbddeeppss((11)). │ │ │ │ │ ******** 33..11..55.. ddppkkgg--ddiissttaaddddffiillee -- aaddddss aa ffiillee ttoo ddeebbiiaann//ffiilleess_? ******** │ │ │ │ │ -Some packages' uploads need to include files other than the source and binary │ │ │ │ │ +Some packages’ uploads need to include files other than the source and binary │ │ │ │ │ package files. │ │ │ │ │ dpkg-distaddfile adds a file to the debian/files file so that it will be │ │ │ │ │ included in the .changes file when dpkg-genchanges is run. │ │ │ │ │ It is usually invoked from the binary target of debian/rules: │ │ │ │ │ dpkg-distaddfile filename section priority │ │ │ │ │ The filename is relative to the directory where dpkg-genchanges will expect to │ │ │ │ │ find it - this is usually the directory above the top level of the source tree. │ │ │ │ │ @@ -141,15 +141,15 @@ │ │ │ │ │ ******** 33..22..22.. ddeebbiiaann//ssuubbssttvvaarrss aanndd vvaarriiaabbllee ssuubbssttiittuuttiioonnss_? ******** │ │ │ │ │ See _V_a_r_i_a_b_l_e_ _s_u_b_s_t_i_t_u_t_i_o_n_s_:_ _d_e_b_i_a_n_/_s_u_b_s_t_v_a_r_s. │ │ │ │ │ ******** 33..22..33.. ddeebbiiaann//ffiilleess_? ******** │ │ │ │ │ See _G_e_n_e_r_a_t_e_d_ _f_i_l_e_s_ _l_i_s_t_:_ _d_e_b_i_a_n_/_f_i_l_e_s. │ │ │ │ │ ******** 33..22..44.. ddeebbiiaann//ttmmpp_? ******** │ │ │ │ │ This is the default temporary location for the construction of binary packages │ │ │ │ │ by the binary target. The directory tmp serves as the root of the file system │ │ │ │ │ -tree as it is being constructed (for example, by using the package's upstream │ │ │ │ │ +tree as it is being constructed (for example, by using the package’s upstream │ │ │ │ │ makefiles install targets and redirecting the output there), and it also │ │ │ │ │ contains the DEBIAN subdirectory. See _C_r_e_a_t_i_n_g_ _p_a_c_k_a_g_e_ _f_i_l_e_s_ _-_ _d_p_k_g_-_d_e_b. │ │ │ │ │ This is only a default and can be easily overridden. Most packaging tools no │ │ │ │ │ longer use debian/tmp, instead preferring debian/pkg for the common case of a │ │ │ │ │ source package building only one binary package. Such tools usually only use │ │ │ │ │ debian/tmp as a temporary staging area for built files and do not construct │ │ │ │ │ packages from it. │ │ │ ├── ./usr/share/doc/debian-policy/policy.html/ap-process.html │ │ │ │ @@ -197,28 +197,28 @@ │ │ │ │ proposal, in which case one may skip this step and move directly to │ │ │ │ patch tag.

│ │ │ │
│ │ │ │
│ │ │ │

8.3.4. State D: Wording proposed

│ │ │ │

A patch against the Policy document reflecting the consensus has been │ │ │ │ created and is waiting for formal seconds. The standard patch tag is │ │ │ │ -used for this state, since it's essentially equivalent to the standard │ │ │ │ +used for this state, since it’s essentially equivalent to the standard │ │ │ │ meaning of that tag.

│ │ │ │

TAG: patch

│ │ │ │

What needs to happen next: The proposal needs to be reviewed and │ │ │ │ seconded. Any Debian developer who agrees with the change and the │ │ │ │ conclusion of rough consensus from the discussion should say so in the │ │ │ │ bug log by seconding the proposal.

│ │ │ │
│ │ │ │
│ │ │ │

8.3.5. State E: Seconded

│ │ │ │

The proposal is signed off on by N Debian Developers. To start with, │ │ │ │ -we're going with N=3, meaning that if three Debian Developers agree, not │ │ │ │ +we’re going with N=3, meaning that if three Debian Developers agree, not │ │ │ │ just with the proposal but with the conclusion that it reflects │ │ │ │ -consensus and addresses the original issue -- it is considered eligible │ │ │ │ +consensus and addresses the original issue – it is considered eligible │ │ │ │ for inclusion in the next version of Policy. Since Policy is partly a │ │ │ │ technical project governance method, one must be a Debian Developer to │ │ │ │ formally second, although review and discussion is welcome from anyone. │ │ │ │ Once this tag has been applied, the bug is waiting for a Policy team │ │ │ │ member to apply the patch to the package repository.

│ │ │ │

TAG: seconded

│ │ │ │

What needs to happen next: A Policy maintainer does the final review and │ │ │ │ @@ -229,27 +229,27 @@ │ │ │ │

│ │ │ │
│ │ │ │

8.3.6. State F: Accepted

│ │ │ │

Change accepted, will be in next upload. The standard pending tag is │ │ │ │ used for this state since it matches the regular meaning of pending.

│ │ │ │

TAG: pending

│ │ │ │

What needs to happen next: The bug is now in the waiting queue for the │ │ │ │ -next Policy release, and there's nothing left to do except for upload a │ │ │ │ +next Policy release, and there’s nothing left to do except for upload a │ │ │ │ new version of Policy.

│ │ │ │
│ │ │ │
│ │ │ │

8.3.7. State G: Reject

│ │ │ │

Rejected proposals. The standard wontfix is used for this state. │ │ │ │ Normally, bugs in this state will not remain open (excepting │ │ │ │ stalled); instead, a Policy team member will close them with an │ │ │ │ explanation. The submitter may then appeal to the tech-ctte if they so │ │ │ │ desire. Alternately, issues appealed to the tech-ctte may remain open │ │ │ │ with this tag while that appeal proceeds.

│ │ │ │

TAG: wontfix

│ │ │ │ -

We may use one of the following tags here. It's not clear whether we │ │ │ │ +

We may use one of the following tags here. It’s not clear whether we │ │ │ │ need more tags for this stage.

│ │ │ │
│ │ │ │
dubious

Not a policy matter

│ │ │ │
│ │ │ │
ctte

Referred to the Technical Committee (tech-ctte)

│ │ │ │
│ │ │ │
devel

Referred to the developer body

│ │ │ │ @@ -292,15 +292,15 @@ │ │ │ │ (used with their normal meanings).

│ │ │ │

TAG: packaging

│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -102,49 +102,49 @@ │ │ │ │ │ What needs to happen next: Provided that the rough consensus persists, develop │ │ │ │ │ a patch against the current Policy document with specific wording of the │ │ │ │ │ change. Often this is done in conjunction with the proposal, in which case one │ │ │ │ │ may skip this step and move directly to patch tag. │ │ │ │ │ ******** 88..33..44.. SSttaattee DD:: WWoorrddiinngg pprrooppoosseedd_? ******** │ │ │ │ │ A patch against the Policy document reflecting the consensus has been created │ │ │ │ │ and is waiting for formal seconds. The standard patch tag is used for this │ │ │ │ │ -state, since it's essentially equivalent to the standard meaning of that tag. │ │ │ │ │ +state, since it’s essentially equivalent to the standard meaning of that tag. │ │ │ │ │ _T_A_G_:_ _p_a_t_c_h │ │ │ │ │ What needs to happen next: The proposal needs to be reviewed and seconded. Any │ │ │ │ │ Debian developer who agrees with the change and the conclusion of rough │ │ │ │ │ consensus from the discussion should say so in the bug log by seconding the │ │ │ │ │ proposal. │ │ │ │ │ ******** 88..33..55.. SSttaattee EE:: SSeeccoonnddeedd_? ******** │ │ │ │ │ -The proposal is signed off on by N Debian Developers. To start with, we're │ │ │ │ │ +The proposal is signed off on by N Debian Developers. To start with, we’re │ │ │ │ │ going with N=3, meaning that if three Debian Developers agree, not just with │ │ │ │ │ the proposal but with the conclusion that it reflects consensus and addresses │ │ │ │ │ -the original issue -- it is considered eligible for inclusion in the next │ │ │ │ │ +the original issue – it is considered eligible for inclusion in the next │ │ │ │ │ version of Policy. Since Policy is partly a technical project governance │ │ │ │ │ method, one must be a Debian Developer to formally second, although review and │ │ │ │ │ discussion is welcome from anyone. Once this tag has been applied, the bug is │ │ │ │ │ waiting for a Policy team member to apply the patch to the package repository. │ │ │ │ │ _T_A_G_:_ _s_e_c_o_n_d_e_d │ │ │ │ │ What needs to happen next: A Policy maintainer does the final review and │ │ │ │ │ confirmation, and then applies the patch for the next Policy release. │ │ │ │ │ This tag is not used very much because normally a Policy maintainer applies the │ │ │ │ │ patch and moves the proposal to the next state once enough seconds are reached. │ │ │ │ │ ******** 88..33..66.. SSttaattee FF:: AAcccceepptteedd_? ******** │ │ │ │ │ Change accepted, will be in next upload. The standard pending tag is used for │ │ │ │ │ this state since it matches the regular meaning of pending. │ │ │ │ │ _T_A_G_:_ _p_e_n_d_i_n_g │ │ │ │ │ What needs to happen next: The bug is now in the waiting queue for the next │ │ │ │ │ -Policy release, and there's nothing left to do except for upload a new version │ │ │ │ │ +Policy release, and there’s nothing left to do except for upload a new version │ │ │ │ │ of Policy. │ │ │ │ │ ******** 88..33..77.. SSttaattee GG:: RReejjeecctt_? ******** │ │ │ │ │ Rejected proposals. The standard wontfix is used for this state. Normally, bugs │ │ │ │ │ in this state will not remain open (excepting ssttaalllleedd); instead, a Policy team │ │ │ │ │ member will close them with an explanation. The submitter may then appeal to │ │ │ │ │ the tech-ctte if they so desire. Alternately, issues appealed to the tech-ctte │ │ │ │ │ may remain open with this tag while that appeal proceeds. │ │ │ │ │ _T_A_G_:_ _w_o_n_t_f_i_x │ │ │ │ │ -We may use one of the following tags here. It's not clear whether we need more │ │ │ │ │ +We may use one of the following tags here. It’s not clear whether we need more │ │ │ │ │ tags for this stage. │ │ │ │ │ dduubbiioouuss │ │ │ │ │ Not a policy matter │ │ │ │ │ ccttttee │ │ │ │ │ Referred to the Technical Committee (tech-ctte) │ │ │ │ │ ddeevveell │ │ │ │ │ Referred to the developer body │ │ │ │ │ @@ -177,11 +177,11 @@ │ │ │ │ │ The packaging tag is used for bugs about the packaging and build process of the │ │ │ │ │ debian-policy Debian package. These bugs do not follow the normal process and │ │ │ │ │ will not have the other tags except for pending and wontfix (used with their │ │ │ │ │ normal meanings). │ │ │ │ │ _T_A_G_:_ _p_a_c_k_a_g_i_n_g │ │ │ │ │ [_1] │ │ │ │ │ This process was originally developed by Margarita Manterola, Clint Adams, Russ │ │ │ │ │ -Allbery and Manoj Srivastava. In 2017, Sean Whitton deprecated the 'issue' │ │ │ │ │ -usertag and added use of the 'moreinfo' tag, after discussions at DebConf17. │ │ │ │ │ +Allbery and Manoj Srivastava. In 2017, Sean Whitton deprecated the ‘issue’ │ │ │ │ │ +usertag and added use of the ‘moreinfo’ tag, after discussions at DebConf17. │ │ │ │ │ _P_r_e_v_i_o_u_s _N_e_x_t │ │ │ │ │ =============================================================================== │ │ │ ├── ./usr/share/doc/debian-policy/policy.html/ch-archive.html │ │ │ │ @@ -136,24 +136,24 @@ │ │ │ │ contrib, non-free) are not considered to be part of the Debian │ │ │ │ distribution, although we support their use and provide infrastructure │ │ │ │ for them (such as our bug-tracking system and mailing lists). This │ │ │ │ Debian Policy Manual applies to these packages as well.

│ │ │ │ │ │ │ │
│ │ │ │

2.1. The Debian Free Software Guidelines

│ │ │ │ -

The Debian Free Software Guidelines (DFSG) form our definition of "free │ │ │ │ -software". These are:

│ │ │ │ +

The Debian Free Software Guidelines (DFSG) form our definition of “free │ │ │ │ +software”. These are:

│ │ │ │
    │ │ │ │
  1. │ │ │ │
    Free Redistribution

    The license of a Debian component may not restrict any party from │ │ │ │ selling or giving away the software as a component of an aggregate │ │ │ │ software distribution containing programs from several different │ │ │ │ sources. The license may not require a royalty or other fee for such │ │ │ │ sale.

    │ │ │ │ @@ -170,17 +170,17 @@ │ │ │ │
    Derived Works

    The license must allow modifications and derived works, and must │ │ │ │ allow them to be distributed under the same terms as the license of │ │ │ │ the original software.

    │ │ │ │
    │ │ │ │
    │ │ │ │
    2. │ │ │ │
  2. │ │ │ │ -
    Integrity of The Author's Source Code

    The license may restrict source-code from being distributed in │ │ │ │ +

    Integrity of The Author’s Source Code

    The license may restrict source-code from being distributed in │ │ │ │ modified form only if the license allows the distribution of │ │ │ │ -"patch files" with the source code for the purpose of modifying the │ │ │ │ +“patch files” with the source code for the purpose of modifying the │ │ │ │ program at build time. The license must explicitly permit │ │ │ │ distribution of software built from modified source code. The │ │ │ │ license may require derived works to carry a different name or │ │ │ │ version number from the original software. (This is a compromise. │ │ │ │ The Debian Project encourages all authors to not restrict any files, │ │ │ │ source or binary, from being modified.)

    │ │ │ │
    │ │ │ │ @@ -204,33 +204,33 @@ │ │ │ │
    Distribution of License

    The rights attached to the program must apply to all to whom the │ │ │ │ program is redistributed without the need for execution of an │ │ │ │ additional license by those parties.

    │ │ │ │
    │ │ │ │
    │ │ │ │
    3. │ │ │ │
  3. │ │ │ │ -
    License Must Not Be Specific to Debian

    The rights attached to the program must not depend on the program's │ │ │ │ +

    License Must Not Be Specific to Debian

    The rights attached to the program must not depend on the program’s │ │ │ │ being part of a Debian system. If the program is extracted from │ │ │ │ Debian and used or distributed without Debian but otherwise within │ │ │ │ -the terms of the program's license, all parties to whom the program │ │ │ │ +the terms of the program’s license, all parties to whom the program │ │ │ │ is redistributed must have the same rights as those that are granted │ │ │ │ in conjunction with the Debian system.

    │ │ │ │
    │ │ │ │
    │ │ │ │
    4. │ │ │ │
  4. │ │ │ │
    License Must Not Contaminate Other Software

    The license must not place restrictions on other software that is │ │ │ │ distributed along with the licensed software. For example, the │ │ │ │ license must not insist that all other programs distributed on the │ │ │ │ same medium must be free software.

    │ │ │ │
    │ │ │ │
    │ │ │ │
    5. │ │ │ │
  5. │ │ │ │ -
    Example Licenses

    The "GPL," "BSD," and "Artistic" licenses are examples of licenses │ │ │ │ +

    Example Licenses

    The “GPL,” “BSD,” and “Artistic” licenses are examples of licenses │ │ │ │ that we consider free.

    │ │ │ │
    │ │ │ │
    │ │ │ │
    6. │ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ @@ -254,15 +254,15 @@ │ │ │ │ alternative for a package in main),

│ │ │ │

  • must not be so buggy that we refuse to support them, and

    • │ │ │ │

  • must meet all policy requirements presented in this manual.

    • │ │ │ │ │ │ │ │

    If a source package is in the main archive area, then at least one of │ │ │ │ its binary packages must be in the main archive area, and each of the │ │ │ │ remaining packages must be in either the main or contrib archive │ │ │ │ -area. Each binary package's archive area is indicated by its Section │ │ │ │ +area. Each binary package’s archive area is indicated by its Section │ │ │ │ field: see Sections.

    │ │ │ │

    Source packages in main with a mixture of main and contrib binary │ │ │ │ packages are more complex for archive tooling to handle, and therefore │ │ │ │ should be limited to situations where it would be inconvenient to split │ │ │ │ the source package. If it is straightforward to split the source package │ │ │ │ into a main part and a contrib part that are built separately, then │ │ │ │ those parts should be represented as separate source packages.

    │ │ │ │ @@ -277,17 +277,17 @@ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
    │ │ │ │
    │ │ │ │

    2.2.2. The non-free-firmware archive area

    │ │ │ │

    The non-free-firmware archive area contains packages providing │ │ │ │ firmware needed to initialize, use or keep updated hardware required │ │ │ │ @@ -412,35 +412,35 @@ │ │ │ │ supposedly-free software. It is often worthwhile contacting such authors │ │ │ │ diplomatically to ask them to modify their license terms. However, this │ │ │ │ can be a politically difficult thing to do and you should ask for advice │ │ │ │ on the debian-legal mailing list first, as explained below.

    │ │ │ │

    When in doubt about a copyright, send mail to │ │ │ │ debian-legal@lists.debian.org. Be prepared to provide us with the │ │ │ │ copyright statement. Software covered by the GPL, public domain software │ │ │ │ -and BSD-like copyrights are safe; be wary of the phrases "commercial use │ │ │ │ -prohibited" and "distribution restricted".

    │ │ │ │ +and BSD-like copyrights are safe; be wary of the phrases “commercial use │ │ │ │ +prohibited” and “distribution restricted”.

    │ │ │ │ │ │ │ │
    │ │ │ │
    │ │ │ │

    2.4. Sections

    │ │ │ │

    The packages in the archive areas main, non-free-firmware, contrib │ │ │ │ and non-free are grouped further into sections to simplify handling.

    │ │ │ │

    The archive area and section for each package should be specified in the │ │ │ │ -package's Section control field (see │ │ │ │ +package’s Section control field (see │ │ │ │ Section). However, the maintainer of the │ │ │ │ Debian archive may override this selection to ensure the consistency of │ │ │ │ the Debian distribution. The Section field should be of the form:

    │ │ │ │
      │ │ │ │

    • section if the package is in the main archive area,

      • │ │ │ │

    • area/section if the package is in the non-free-firmware, contrib │ │ │ │ or non-free archive areas.

      • │ │ │ │ @@ -458,15 +458,15 @@ │ │ │ │

      For more information about the sections and their definitions, see the │ │ │ │ list of sections in │ │ │ │ unstable.

      │ │ │ │
    │ │ │ │
    │ │ │ │

    2.5. Priorities

    │ │ │ │

    Each package must have a priority value, which is set in the metadata │ │ │ │ -for the Debian archive and is also included in the package's control │ │ │ │ +for the Debian archive and is also included in the package’s control │ │ │ │ files (see Priority). This information is used │ │ │ │ to control which packages are included in standard or minimal Debian │ │ │ │ installations.

    │ │ │ │

    Most Debian packages will have a priority of optional. Priority │ │ │ │ levels other than optional are only used for packages that should be │ │ │ │ included by default in a standard installation of Debian.

    │ │ │ │

    The priority of a package is determined solely by the functionality it │ │ │ │ @@ -490,25 +490,25 @@ │ │ │ │ to put things back, so only do so if you know what you are doing.

    │ │ │ │

    Systems with only the required packages installed have at least │ │ │ │ enough functionality for the sysadmin to boot the system and install │ │ │ │ more software.

    │ │ │ │ │ │ │ │
    important

    Important programs, including those which one would expect to find │ │ │ │ on any Unix-like system. If the expectation is that an experienced │ │ │ │ -Unix person who found it missing would say "What on earth is going │ │ │ │ -on, where is foo?", it must be an important package. [6] │ │ │ │ +Unix person who found it missing would say “What on earth is going │ │ │ │ +on, where is foo?”, it must be an important package. [6] │ │ │ │ Other packages without which the system will not run well or be │ │ │ │ usable must also have priority important. This does not │ │ │ │ include Emacs, the X Window System, TeX or any other large │ │ │ │ applications. The important packages are just a bare minimum of │ │ │ │ commonly-expected and necessary tools.

    │ │ │ │
    │ │ │ │
    standard

    These packages provide a reasonably small but not too limited │ │ │ │ character-mode system. This is what will be installed by default if │ │ │ │ -the user doesn't select anything else. It doesn't include many large │ │ │ │ +the user doesn’t select anything else. It doesn’t include many large │ │ │ │ applications.

    │ │ │ │

    Two packages that both have a priority of standard or higher must │ │ │ │ not conflict with each other.

    │ │ │ │
    │ │ │ │
    optional

    This is the default priority for the majority of the archive. Unless │ │ │ │ a package should be installed by default on standard Debian systems, │ │ │ │ it should have a priority of optional. Packages with a priority │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -57,38 +57,38 @@ │ │ │ │ │ laws. │ │ │ │ │ The mmaaiinn archive area forms the DDeebbiiaann ddiissttrriibbuuttiioonn. │ │ │ │ │ Packages in the other archive areas (non-free-firmware, contrib, non-free) are │ │ │ │ │ not considered to be part of the Debian distribution, although we support their │ │ │ │ │ use and provide infrastructure for them (such as our bug-tracking system and │ │ │ │ │ mailing lists). This Debian Policy Manual applies to these packages as well. │ │ │ │ │ [_1] │ │ │ │ │ -The Debian archive software uses the term "component" internally and in the │ │ │ │ │ +The Debian archive software uses the term “component” internally and in the │ │ │ │ │ Release file format to refer to the division of an archive. The Debian Social │ │ │ │ │ -Contract simply refers to "areas." This document uses terminology similar to │ │ │ │ │ +Contract simply refers to “areas.” This document uses terminology similar to │ │ │ │ │ the Social Contract. │ │ │ │ │ ********** 22..11.. TThhee DDeebbiiaann FFrreeee SSooffttwwaarree GGuuiiddeelliinneess_? ********** │ │ │ │ │ -The Debian Free Software Guidelines (DFSG) form our definition of "free │ │ │ │ │ -software". These are: │ │ │ │ │ +The Debian Free Software Guidelines (DFSG) form our definition of “free │ │ │ │ │ +software”. These are: │ │ │ │ │ 1. Free Redistribution │ │ │ │ │ The license of a Debian component may not restrict any party from │ │ │ │ │ selling or giving away the software as a component of an aggregate │ │ │ │ │ software distribution containing programs from several different │ │ │ │ │ sources. The license may not require a royalty or other fee for │ │ │ │ │ such sale. │ │ │ │ │ 2. Source Code │ │ │ │ │ The program must include source code, and must allow distribution │ │ │ │ │ in source code as well as compiled form. │ │ │ │ │ 3. Derived Works │ │ │ │ │ The license must allow modifications and derived works, and must │ │ │ │ │ allow them to be distributed under the same terms as the license of │ │ │ │ │ the original software. │ │ │ │ │ - 4. Integrity of The Author's Source Code │ │ │ │ │ + 4. Integrity of The Author’s Source Code │ │ │ │ │ The license may restrict source-code from being distributed in │ │ │ │ │ - modified form oonnllyy if the license allows the distribution of "patch │ │ │ │ │ - files" with the source code for the purpose of modifying the │ │ │ │ │ + modified form oonnllyy if the license allows the distribution of “patch │ │ │ │ │ + files” with the source code for the purpose of modifying the │ │ │ │ │ program at build time. The license must explicitly permit │ │ │ │ │ distribution of software built from modified source code. The │ │ │ │ │ license may require derived works to carry a different name or │ │ │ │ │ version number from the original software. (This is a compromise. │ │ │ │ │ The Debian Project encourages all authors to not restrict any │ │ │ │ │ files, source or binary, from being modified.) │ │ │ │ │ 5. No Discrimination Against Persons or Groups │ │ │ │ │ @@ -100,27 +100,27 @@ │ │ │ │ │ the program from being used in a business, or from being used for │ │ │ │ │ genetic research. │ │ │ │ │ 7. Distribution of License │ │ │ │ │ The rights attached to the program must apply to all to whom the │ │ │ │ │ program is redistributed without the need for execution of an │ │ │ │ │ additional license by those parties. │ │ │ │ │ 8. License Must Not Be Specific to Debian │ │ │ │ │ - The rights attached to the program must not depend on the program's │ │ │ │ │ + The rights attached to the program must not depend on the program’s │ │ │ │ │ being part of a Debian system. If the program is extracted from │ │ │ │ │ Debian and used or distributed without Debian but otherwise within │ │ │ │ │ - the terms of the program's license, all parties to whom the program │ │ │ │ │ + the terms of the program’s license, all parties to whom the program │ │ │ │ │ is redistributed must have the same rights as those that are │ │ │ │ │ granted in conjunction with the Debian system. │ │ │ │ │ 9. License Must Not Contaminate Other Software │ │ │ │ │ The license must not place restrictions on other software that is │ │ │ │ │ distributed along with the licensed software. For example, the │ │ │ │ │ license must not insist that all other programs distributed on the │ │ │ │ │ same medium must be free software. │ │ │ │ │ 10. Example Licenses │ │ │ │ │ - The "GPL," "BSD," and "Artistic" licenses are examples of licenses │ │ │ │ │ + The “GPL,” “BSD,” and “Artistic” licenses are examples of licenses │ │ │ │ │ that we consider ffrreeee. │ │ │ │ │ ********** 22..22.. AArrcchhiivvee aarreeaass_? ********** │ │ │ │ │ ******** 22..22..11.. TThhee mmaaiinn aarrcchhiivvee aarreeaa_? ******** │ │ │ │ │ The mmaaiinn archive area comprises the Debian distribution. Only the packages in │ │ │ │ │ this area are considered part of the distribution. None of the packages in the │ │ │ │ │ mmaaiinn archive area require software outside of that area to function. Anyone may │ │ │ │ │ use, share, modify and redistribute the packages in this archive area freely │ │ │ │ │ @@ -134,15 +134,15 @@ │ │ │ │ │ relationship on a non-mmaaiinn package unless that package is only listed as │ │ │ │ │ a non-default alternative for a package in mmaaiinn), │ │ │ │ │ * must not be so buggy that we refuse to support them, and │ │ │ │ │ * must meet all policy requirements presented in this manual. │ │ │ │ │ If a source package is in the mmaaiinn archive area, then at least one of its │ │ │ │ │ binary packages must be in the mmaaiinn archive area, and each of the remaining │ │ │ │ │ packages must be in either the mmaaiinn or ccoonnttrriibb archive area. Each binary │ │ │ │ │ -package's archive area is indicated by its Section field: see _S_e_c_t_i_o_n_s. │ │ │ │ │ +package’s archive area is indicated by its Section field: see _S_e_c_t_i_o_n_s. │ │ │ │ │ Source packages in mmaaiinn with a mixture of mmaaiinn and ccoonnttrriibb binary packages are │ │ │ │ │ more complex for archive tooling to handle, and therefore should be limited to │ │ │ │ │ situations where it would be inconvenient to split the source package. If it is │ │ │ │ │ straightforward to split the source package into a mmaaiinn part and a ccoonnttrriibb part │ │ │ │ │ that are built separately, then those parts should be represented as separate │ │ │ │ │ source packages. │ │ │ │ │ When a mmaaiinn source package has a mixture of mmaaiinn and ccoonnttrriibb binary packages, │ │ │ │ │ @@ -150,15 +150,15 @@ │ │ │ │ │ for mmaaiinn packages, but the ccoonnttrriibb binary packages may follow the weaker │ │ │ │ │ requirements for ccoonnttrriibb packages. In particular, source packages in mmaaiinn must │ │ │ │ │ not have build dependencies outside mmaaiinn, but the ccoonnttrriibb binary packages may │ │ │ │ │ have runtime dependencies outside mmaaiinn. │ │ │ │ │ [_2] │ │ │ │ │ See _W_h_a_t_ _D_o_e_s_ _F_r_e_e_ _M_e_a_n_? for more about what we mean by free software. │ │ │ │ │ [_3] │ │ │ │ │ -Debian's FTP Masters publish a _R_E_J_E_C_T_-_F_A_Q which details the project's current │ │ │ │ │ +Debian’s FTP Masters publish a _R_E_J_E_C_T_-_F_A_Q which details the project’s current │ │ │ │ │ working interpretation of the DFSG. │ │ │ │ │ ******** 22..22..22.. TThhee nnoonn--ffrreeee--ffiirrmmwwaarree aarrcchhiivvee aarreeaa_? ******** │ │ │ │ │ The nnoonn--ffrreeee--ffiirrmmwwaarree archive area contains packages providing firmware needed │ │ │ │ │ to initialize, use or keep updated hardware required by our users, typically │ │ │ │ │ necessary for important functions to be available (i.e. wireless network │ │ │ │ │ connectivity) or for fixing security defects in hardware (i.e. CPU microcode │ │ │ │ │ updates). Packages in this archive may not comply with all of the policy │ │ │ │ │ @@ -249,27 +249,27 @@ │ │ │ │ │ software. It is often worthwhile contacting such authors diplomatically to ask │ │ │ │ │ them to modify their license terms. However, this can be a politically │ │ │ │ │ difficult thing to do and you should ask for advice on the debian-legal mailing │ │ │ │ │ list first, as explained below. │ │ │ │ │ When in doubt about a copyright, send mail to _d_e_b_i_a_n_-_l_e_g_a_l_@_l_i_s_t_s_._d_e_b_i_a_n_._o_r_g. Be │ │ │ │ │ prepared to provide us with the copyright statement. Software covered by the │ │ │ │ │ GPL, public domain software and BSD-like copyrights are safe; be wary of the │ │ │ │ │ -phrases "commercial use prohibited" and "distribution restricted". │ │ │ │ │ +phrases “commercial use prohibited” and “distribution restricted”. │ │ │ │ │ [_5] │ │ │ │ │ Licenses that are not thought to require the copying of all copyright notices │ │ │ │ │ -into Debian's copyright file include Apache-2.0 and the Boost Software License, │ │ │ │ │ -version 1.0. Final determination as to whether a package's copyright file is │ │ │ │ │ +into Debian’s copyright file include Apache-2.0 and the Boost Software License, │ │ │ │ │ +version 1.0. Final determination as to whether a package’s copyright file is │ │ │ │ │ sufficient lies with the FTP team. │ │ │ │ │ To help find copyright notices you need to copy, you might try grep -- │ │ │ │ │ color=always -Eir '(copyright|©)' * | less -R │ │ │ │ │ ********** 22..44.. SSeeccttiioonnss_? ********** │ │ │ │ │ The packages in the archive areas mmaaiinn, nnoonn--ffrreeee--ffiirrmmwwaarree, ccoonnttrriibb and nnoonn--ffrreeee │ │ │ │ │ are grouped further into sseeccttiioonnss to simplify handling. │ │ │ │ │ The archive area and section for each package should be specified in the │ │ │ │ │ -package's Section control field (see _S_e_c_t_i_o_n). However, the maintainer of the │ │ │ │ │ +package’s Section control field (see _S_e_c_t_i_o_n). However, the maintainer of the │ │ │ │ │ Debian archive may override this selection to ensure the consistency of the │ │ │ │ │ Debian distribution. The Section field should be of the form: │ │ │ │ │ * sseeccttiioonn if the package is in the mmaaiinn archive area, │ │ │ │ │ * aarreeaa//sseeccttiioonn if the package is in the nnoonn--ffrreeee--ffiirrmmwwaarree, ccoonnttrriibb or nnoonn-- │ │ │ │ │ ffrreeee archive areas. │ │ │ │ │ The Debian archive maintainers provide the authoritative list of sections. At │ │ │ │ │ present, they are: admin, cli-mono, comm, database, debug, devel, doc, editors, │ │ │ │ │ @@ -280,15 +280,15 @@ │ │ │ │ │ ruby, rust, science, shells, sound, tasks, tex, text, utils, vcs, video, web, │ │ │ │ │ x11, xfce, zope. The additional section ddeebbiiaann--iinnssttaalllleerr contains special │ │ │ │ │ packages used by the installer and is not used for normal Debian packages. │ │ │ │ │ For more information about the sections and their definitions, see the _l_i_s_t_ _o_f │ │ │ │ │ _s_e_c_t_i_o_n_s_ _i_n_ _u_n_s_t_a_b_l_e. │ │ │ │ │ ********** 22..55.. PPrriioorriittiieess_? ********** │ │ │ │ │ Each package must have a pprriioorriittyy value, which is set in the metadata for the │ │ │ │ │ -Debian archive and is also included in the package's control files (see │ │ │ │ │ +Debian archive and is also included in the package’s control files (see │ │ │ │ │ _P_r_i_o_r_i_t_y). This information is used to control which packages are included in │ │ │ │ │ standard or minimal Debian installations. │ │ │ │ │ Most Debian packages will have a priority of optional. Priority levels other │ │ │ │ │ than optional are only used for packages that should be included by default in │ │ │ │ │ a standard installation of Debian. │ │ │ │ │ The priority of a package is determined solely by the functionality it provides │ │ │ │ │ directly to the user. The priority of a package should not be increased merely │ │ │ │ │ @@ -310,24 +310,24 @@ │ │ │ │ │ only do so if you know what you are doing. │ │ │ │ │ Systems with only the required packages installed have at least enough │ │ │ │ │ functionality for the sysadmin to boot the system and install more │ │ │ │ │ software. │ │ │ │ │ important │ │ │ │ │ Important programs, including those which one would expect to find on any │ │ │ │ │ Unix-like system. If the expectation is that an experienced Unix person │ │ │ │ │ - who found it missing would say "What on earth is going on, where is │ │ │ │ │ - foo?", it must be an important package. _[_6_] Other packages without which │ │ │ │ │ + who found it missing would say “What on earth is going on, where is │ │ │ │ │ + foo?”, it must be an important package. _[_6_] Other packages without which │ │ │ │ │ the system will not run well or be usable must also have priority │ │ │ │ │ important. This does nnoott include Emacs, the X Window System, TeX or any │ │ │ │ │ other large applications. The important packages are just a bare minimum │ │ │ │ │ of commonly-expected and necessary tools. │ │ │ │ │ standard │ │ │ │ │ These packages provide a reasonably small but not too limited character- │ │ │ │ │ mode system. This is what will be installed by default if the user │ │ │ │ │ - doesn't select anything else. It doesn't include many large applications. │ │ │ │ │ + doesn’t select anything else. It doesn’t include many large applications. │ │ │ │ │ Two packages that both have a priority of standard or higher must not │ │ │ │ │ conflict with each other. │ │ │ │ │ optional │ │ │ │ │ This is the default priority for the majority of the archive. Unless a │ │ │ │ │ package should be installed by default on standard Debian systems, it │ │ │ │ │ should have a priority of optional. Packages with a priority of optional │ │ │ │ │ may conflict with each other. │ │ │ ├── ./usr/share/doc/debian-policy/policy.html/ch-binary.html │ │ │ │ @@ -133,40 +133,40 @@ │ │ │ │ on the system when the package is installed, and a set of files that │ │ │ │ provide additional metadata about the package or which are executed when │ │ │ │ the package is installed or removed. This second set of files is called │ │ │ │ package metadata files. Among those files are the package maintainer │ │ │ │ scripts and control, the binary package control file that contains the control fields for the │ │ │ │ package. Other package metadata files include symbols or shlibs used to │ │ │ │ store shared library dependency information and the conffiles file │ │ │ │ -that lists the package's configuration files (described in │ │ │ │ +that lists the package’s configuration files (described in │ │ │ │ Configuration files).

    │ │ │ │

    There is unfortunately a collision of terminology here between control │ │ │ │ information files and files in the Debian control file format. │ │ │ │ Throughout this document, a control file refers to a file in the │ │ │ │ Debian control file format. These files are documented in │ │ │ │ Control files and their fields. Only files │ │ │ │ referred to specifically as package metadata files are the files │ │ │ │ included in the package metadata member (called control.tar) of the │ │ │ │ .deb file format used by binary packages. Most package metadata files │ │ │ │ are not in the Debian control file format.

    │ │ │ │
    │ │ │ │

    3.1. The package name

    │ │ │ │ -

    Every package must have a name that's unique within the Debian archive.

    │ │ │ │ +

    Every package must have a name that’s unique within the Debian archive.

    │ │ │ │

    The package name is included in the control field Package, the │ │ │ │ format of which is described in Package. The │ │ │ │ package name is also included as a part of the file name of the .deb │ │ │ │ file.

    │ │ │ │
    │ │ │ │

    3.1.1. Packages with potentially offensive content

    │ │ │ │

    As a maintainer you should make a judgement about whether the contents │ │ │ │ of a package is appropriate to include, whether it needs any kind of │ │ │ │ content warning, and whether some parts should be split out into a │ │ │ │ separate package (so that users who want to avoid certain parts can do │ │ │ │ so). In making these decisions you should take into account the │ │ │ │ -project's views as expressed in our Diversity Statement.

    │ │ │ │ +project’s views as expressed in our Diversity Statement.

    │ │ │ │

    If you split out (potentially) offensive or disturbing material into a │ │ │ │ separate package, you should usually mark this in the package name by │ │ │ │ adding -offensive. For example, cowsay vs │ │ │ │ cowsay-offensive. In this situation the -offensive package │ │ │ │ can be Suggested by the core package(s), but should not be Recommended │ │ │ │ or Depended on.

    │ │ │ │
    │ │ │ │ @@ -183,17 +183,17 @@ │ │ │ │ comparison is concerned) at the beginning.

    │ │ │ │

    If an upstream package has problematic version numbers they should be │ │ │ │ converted to a sane form for use in the Version field.

    │ │ │ │
    │ │ │ │

    3.2.1. Version numbers based on dates

    │ │ │ │

    In general, Debian packages should use the same version numbers as the │ │ │ │ upstream sources. However, upstream version numbers based on some date │ │ │ │ -formats (sometimes used for development or "snapshot" releases) will not │ │ │ │ +formats (sometimes used for development or “snapshot” releases) will not │ │ │ │ be ordered correctly by the package management software. For example, │ │ │ │ -dpkg will consider "96May01" to be greater than "96Dec24".

    │ │ │ │ +dpkg will consider “96May01” to be greater than “96Dec24”.

    │ │ │ │

    To prevent having to use epochs for every new upstream version, the │ │ │ │ date-based portion of any upstream version number should be given in a │ │ │ │ way that sorts correctly: four-digit year first, followed by a two-digit │ │ │ │ numeric month, followed by a two-digit numeric date, possibly with │ │ │ │ punctuation between the components.

    │ │ │ │

    Native Debian packages (i.e., packages which have been written │ │ │ │ especially for Debian) whose version numbers include dates should also │ │ │ │ @@ -221,15 +221,15 @@ │ │ │ │

    The reason for these restrictions is as follows. Epochs are not │ │ │ │ included in the names of the files that compose source packages, or in │ │ │ │ the filenames of binary packages, so reusing a version number, even if │ │ │ │ the epoch differs, results in identically named files with different │ │ │ │ contents. This can cause various problems.

    │ │ │ │

    If you find yourself wanting to reuse the part of a version number │ │ │ │ after the epoch, you can just increment the Debian revision, which │ │ │ │ -doesn't need to start at 1 or be consecutive.

    │ │ │ │ +doesn’t need to start at 1 or be consecutive.

    │ │ │ │
    │ │ │ │
    │ │ │ │
    │ │ │ │

    3.3. The maintainer of a package

    │ │ │ │

    Every package must have a maintainer, except for orphaned packages as │ │ │ │ described below. The maintainer may be one person or a group of people │ │ │ │ reachable from a common email address, such as a mailing list. The │ │ │ │ @@ -266,30 +266,30 @@ │ │ │ │

    Every Debian package must have a Description control field which │ │ │ │ contains a synopsis and extended description of the package. Technical │ │ │ │ information about the format of the Description field is in │ │ │ │ Description.

    │ │ │ │

    The description should describe the package (the program) to a user │ │ │ │ (system administrator) who has never met it before so that they have │ │ │ │ enough information to decide whether they want to install it. This │ │ │ │ -description should not just be copied verbatim from the program's │ │ │ │ +description should not just be copied verbatim from the program’s │ │ │ │ documentation.

    │ │ │ │

    Put important information first, both in the synopsis and extended │ │ │ │ description. Sometimes only the first part of the synopsis or of the │ │ │ │ description will be displayed. You can assume that there will usually be │ │ │ │ a way to see the whole extended description.

    │ │ │ │

    The description should also give information about the significant │ │ │ │ dependencies and conflicts between this package and others, so that the │ │ │ │ user knows why these dependencies and conflicts have been declared.

    │ │ │ │

    Instructions for configuring or using the package should not be included │ │ │ │ (that is what installation scripts, manual pages, info files, etc., are │ │ │ │ for). Copyright statements and other administrivia should not be │ │ │ │ included either (that is what the copyright file is for).

    │ │ │ │
    │ │ │ │

    3.4.1. The single line synopsis

    │ │ │ │ -

    The single line synopsis should be kept brief---certainly under 80 │ │ │ │ +

    The single line synopsis should be kept brief—certainly under 80 │ │ │ │ characters.

    │ │ │ │

    Do not include the package name in the synopsis line. The display │ │ │ │ software knows how to display this already, and you do not need to state │ │ │ │ it. Remember that in many situations the user may only see the synopsis │ │ │ │ line - make it as informative as you can.

    │ │ │ │
    │ │ │ │
    │ │ │ │ @@ -323,17 +323,17 @@ │ │ │ │ about doing that has been reached.

    │ │ │ │

    The format of the package interrelationship control fields is described │ │ │ │ in Declaring relationships between packages.

    │ │ │ │
    │ │ │ │
    │ │ │ │

    3.6. Virtual packages

    │ │ │ │

    Sometimes, there are several packages which offer more-or-less the same │ │ │ │ -functionality. In this case, it's useful to define a virtual package │ │ │ │ +functionality. In this case, it’s useful to define a virtual package │ │ │ │ whose name describes that common functionality. (The virtual packages │ │ │ │ -only exist logically, not physically; that's why they are called │ │ │ │ +only exist logically, not physically; that’s why they are called │ │ │ │ virtual.) The packages with this particular function will then │ │ │ │ provide the virtual package. Thus, any other package requiring that │ │ │ │ function can simply depend on the virtual package without having to │ │ │ │ specify all possible packages individually.

    │ │ │ │

    All packages should use virtual package names where appropriate, and │ │ │ │ arrange to create new ones if necessary. They should not use virtual │ │ │ │ package names (except privately, amongst a cooperating group of │ │ │ │ @@ -356,15 +356,15 @@ │ │ │ │ required or important. Many of them will be tagged essential │ │ │ │ (see below).

    │ │ │ │
    │ │ │ │
    │ │ │ │

    3.8. Essential packages

    │ │ │ │

    Essential is defined as the minimal set of functionality that must be │ │ │ │ available and usable on the system at all times, even when packages are │ │ │ │ -in the "Unpacked" state. Packages are tagged essential for a system │ │ │ │ +in the “Unpacked” state. Packages are tagged essential for a system │ │ │ │ using the Essential control field. The format of the Essential │ │ │ │ control field is described in Essential.

    │ │ │ │

    Since these packages cannot be easily removed (one has to specify an │ │ │ │ extra force option to dpkg to do so), this flag must not be used │ │ │ │ unless absolutely necessary. A shared library package must not be tagged │ │ │ │ essential; dependencies will prevent its premature removal, and we │ │ │ │ need to be able to remove it when it has been superseded.

    │ │ │ │ @@ -460,44 +460,44 @@ │ │ │ │

    Packages should try to minimize the amount of prompting they need to do, │ │ │ │ and they should ensure that the user will only ever be asked each │ │ │ │ question once. This means that packages should try to use appropriate │ │ │ │ shared configuration files (such as /etc/papersize and │ │ │ │ /etc/news/server), and shared debconf variables rather than each │ │ │ │ prompting for their own list of required pieces of information.

    │ │ │ │

    It also means that an upgrade should not ask the same questions again, │ │ │ │ -unless the user has used dpkg --purge to remove the package's │ │ │ │ +unless the user has used dpkg --purge to remove the package’s │ │ │ │ configuration. The answers to configuration questions should be stored │ │ │ │ in an appropriate place in /etc so that the user can modify them, │ │ │ │ and how this has been done should be documented.

    │ │ │ │

    If a package has a vitally important piece of information to pass to the │ │ │ │ -user (such as "don't run me as I am, you must edit the following │ │ │ │ +user (such as “don’t run me as I am, you must edit the following │ │ │ │ configuration files first or you risk your system emitting │ │ │ │ -badly-formatted messages"), it should display this in the config or │ │ │ │ +badly-formatted messages”), it should display this in the config or │ │ │ │ postinst script and prompt the user to hit return to acknowledge the │ │ │ │ message. Copyright messages do not count as vitally important (they │ │ │ │ belong in /usr/share/doc/PACKAGE/copyright); neither do instructions │ │ │ │ on how to use a program (these should be in on-line documentation, where │ │ │ │ all the users can see them).

    │ │ │ │

    Any necessary prompting should almost always be confined to the │ │ │ │ config or postinst script. If it is done in the postinst, it │ │ │ │ should be protected with a conditional so that unnecessary prompting │ │ │ │ -doesn't happen if a package's installation fails and the postinst is │ │ │ │ +doesn’t happen if a package’s installation fails and the postinst is │ │ │ │ called with abort-upgrade, abort-remove or │ │ │ │ abort-deconfigure.

    │ │ │ │
    │ │ │ │
    │ │ │ │ -

    5.2. Debian source package template control files -- debian/control

    │ │ │ │ +

    5.2. Debian source package template control files – debian/control

    │ │ │ │

    The debian/control file contains the most vital (and │ │ │ │ version-independent) information about the source package and about the │ │ │ │ binary packages it creates.

    │ │ │ │

    The first stanza of the control file contains information about the │ │ │ │ source package in general. The subsequent stanzas each describe a │ │ │ │ binary package that the source tree builds. Each binary package built │ │ │ │ from this source package has a corresponding stanza, except for any │ │ │ │ @@ -277,15 +277,15 @@ │ │ │ │ fields.

    │ │ │ │

    The fields here may contain variable references - their values will be │ │ │ │ substituted by dpkg-gencontrol, dpkg-genchanges or │ │ │ │ dpkg-source when they generate output control files. See │ │ │ │ Variable substitutions: debian/substvars for details.

    │ │ │ │
    │ │ │ │
    │ │ │ │ -

    5.3. Debian binary package control files -- DEBIAN/control

    │ │ │ │ +

    5.3. Debian binary package control files – DEBIAN/control

    │ │ │ │

    The DEBIAN/control file contains the most vital (and │ │ │ │ version-dependent) information about a binary package. It consists of a │ │ │ │ single stanza.

    │ │ │ │

    The fields in this file are:

    │ │ │ │ │ │ │ │
    │ │ │ │
    │ │ │ │ -

    5.4. Debian source package control files -- .dsc

    │ │ │ │ +

    5.4. Debian source package control files – .dsc

    │ │ │ │

    This file consists of a single stanza, possibly surrounded by an OpenPGP │ │ │ │ signature. The fields of that stanza are listed below. Their syntax │ │ │ │ is described above, in Syntax of control files.

    │ │ │ │
      │ │ │ │

    • Format (mandatory)

      • │ │ │ │

    • Source (mandatory)

      • │ │ │ │

    • Binary

      • │ │ │ │ @@ -328,15 +328,15 @@ │ │ │ │
    │ │ │ │

    The Debian source package control file is generated by dpkg-source when it │ │ │ │ builds the source archive, from other files in the source package, │ │ │ │ described above. When unpacking, it is checked against the files and │ │ │ │ directories in the other parts of the source package.

    │ │ │ │
    │ │ │ │
    │ │ │ │ -

    5.5. Debian upload changes control files -- .changes

    │ │ │ │ +

    5.5. Debian upload changes control files – .changes

    │ │ │ │

    The .changes files are used by the Debian archive maintenance │ │ │ │ software to process updates to packages. They consist of a single │ │ │ │ stanza, possibly surrounded by an OpenPGP signature. That stanza │ │ │ │ contains information from the debian/control file and other data │ │ │ │ about the source package gathered via debian/changelog and │ │ │ │ debian/rules.

    │ │ │ │

    .changes files have a format version that is incremented whenever │ │ │ │ @@ -380,18 +380,18 @@ │ │ │ │ Package) must consist only of lower case │ │ │ │ letters (a-z), digits (0-9), plus (+) and minus (-) │ │ │ │ signs, and periods (.). They must be at least two characters long │ │ │ │ and must start with an alphanumeric character.

    │ │ │ │
    │ │ │ │
    │ │ │ │

    5.6.2. Maintainer

    │ │ │ │ -

    The package maintainer's name and email address. The name must come │ │ │ │ +

    The package maintainer’s name and email address. The name must come │ │ │ │ first, then the email address inside angle brackets <> (in RFC822 │ │ │ │ format).

    │ │ │ │ -

    If the maintainer's name contains a full stop then the whole field will │ │ │ │ +

    If the maintainer’s name contains a full stop then the whole field will │ │ │ │ not work directly as an email address due to a misfeature in the syntax │ │ │ │ specified in RFC822; a program using this field as an address must check │ │ │ │ for this and correct the problem if necessary (for example by putting │ │ │ │ the name in round brackets and moving it to the end, and bringing the │ │ │ │ email address forward).

    │ │ │ │

    See The maintainer of a package for additional requirements and │ │ │ │ information about package maintainers.

    │ │ │ │ @@ -475,21 +475,21 @@ │ │ │ │ value allowed in the list is all.

    │ │ │ │

    The list may include (or consist solely of) the special value all. │ │ │ │ In other words, in .dsc files unlike the debian/control, all │ │ │ │ may occur in combination with specific architectures. The │ │ │ │ Architecture field in the Debian source package control file .dsc is │ │ │ │ generally constructed from the Architecture fields in the │ │ │ │ debian/control in the source package.

    │ │ │ │ -

    Specifying only any indicates that the source package isn't │ │ │ │ +

    Specifying only any indicates that the source package isn’t │ │ │ │ dependent on any particular architecture and should compile fine on any │ │ │ │ one. The produced binary package(s) will be specific to whatever the │ │ │ │ current build architecture is.

    │ │ │ │

    Specifying only all indicates that the source package will only │ │ │ │ build architecture-independent packages.

    │ │ │ │ -

    Specifying any all indicates that the source package isn't dependent │ │ │ │ +

    Specifying any all indicates that the source package isn’t dependent │ │ │ │ on any particular architecture. The set of produced binary packages will │ │ │ │ include at least one architecture-dependent package and one │ │ │ │ architecture-independent package.

    │ │ │ │

    Specifying a list of architectures or architecture wildcards indicates │ │ │ │ that the source will build an architecture-dependent package, and will │ │ │ │ only work correctly on the listed or matching architectures. If the │ │ │ │ source package also builds at least one architecture-independent │ │ │ │ @@ -512,15 +512,15 @@ │ │ │ │

    If set to yes then the package management system will refuse to │ │ │ │ remove the package (upgrading and replacing it is still possible). The │ │ │ │ other possible value is no, which is the same as not having the │ │ │ │ field at all.

    │ │ │ │
    │ │ │ │
    │ │ │ │

    5.6.10. Package interrelationship fields: Depends, Pre-Depends, Recommends, Suggests, Breaks, Conflicts, Provides, Replaces, Enhances

    │ │ │ │ -

    These fields describe the package's relationships with other packages. │ │ │ │ +

    These fields describe the package’s relationships with other packages. │ │ │ │ Their syntax and semantics are described in │ │ │ │ Declaring relationships between packages.

    │ │ │ │
    │ │ │ │
    │ │ │ │

    5.6.11. Standards-Version

    │ │ │ │

    The most recent version of the standards (the policy manual and │ │ │ │ associated texts) with which the package complies. See │ │ │ │ @@ -550,19 +550,19 @@ │ │ │ │ omitted, in which case zero is assumed.

    │ │ │ │

    Epochs can help when the upstream version numbering scheme │ │ │ │ changes, but they must be used with care. You should not change │ │ │ │ the epoch, even in experimental, without getting consensus on │ │ │ │ debian-devel first.

    │ │ │ │
    │ │ │ │
    upstream_version

    This is the main part of the version number. It is usually the │ │ │ │ -version number of the original ("upstream") package from which the │ │ │ │ +version number of the original (“upstream”) package from which the │ │ │ │ .deb file has been made, if this is applicable. Usually this │ │ │ │ will be in the same format as that specified by the upstream │ │ │ │ author(s); however, it may need to be reformatted to fit into the │ │ │ │ -package management system's format and comparison scheme.

    │ │ │ │ +package management system’s format and comparison scheme.

    │ │ │ │

    The comparison behavior of the package management system with │ │ │ │ respect to the upstream_version is described below. The │ │ │ │ upstream_version portion of the version number is mandatory.

    │ │ │ │

    The upstream_version must contain only alphanumerics [6] and │ │ │ │ the characters . + - ~ (full stop, plus, hyphen, │ │ │ │ tilde) and should start with a digit. If there is no │ │ │ │ debian_revision then hyphens are not allowed.

    │ │ │ │ @@ -694,15 +694,15 @@ │ │ │ │

    If there were no unstable 1.5-1 package, but there were a stable │ │ │ │ update to an upstream 1.5 release, the first such stable update would │ │ │ │ have the version 1.5-0+deb10u1.

    │ │ │ │ │ │ │ │

  • upstream_version components in native packages ending in +debNuX │ │ │ │ indicate a stable update. This is a version of the package uploaded │ │ │ │ directly to a stable release, and the version is chosen to sort before any │ │ │ │ -later version of the package uploaded to Debian's unstable or a later stable │ │ │ │ +later version of the package uploaded to Debian’s unstable or a later stable │ │ │ │ distribution. As with non-native packages, N is the major version │ │ │ │ number of the Debian stable release to which the package was uploaded, and │ │ │ │ X is a number, starting at 1, that is increased for each stable upload │ │ │ │ of this package.

    │ │ │ │

    For example, suppose Debian 10 released with a package with version │ │ │ │ 1.4. The first stable update of that package would have the version │ │ │ │ 1.4+deb10u1, and a subsequent update would have the version │ │ │ │ @@ -748,15 +748,15 @@ │ │ │ │

      │ │ │ │

    • Those starting with a single space are part of a paragraph. │ │ │ │ Successive lines of this form will be word-wrapped when displayed. │ │ │ │ The leading space will usually be stripped off. The line must contain │ │ │ │ at least one non-whitespace character.

      • │ │ │ │

    • Those starting with two or more spaces. These will be displayed │ │ │ │ verbatim. If the display cannot be panned horizontally, the │ │ │ │ -displaying program will line wrap them "hard" (i.e., without taking │ │ │ │ +displaying program will line wrap them “hard” (i.e., without taking │ │ │ │ account of word breaks). If it can they will be allowed to trail off │ │ │ │ to the right. None, one or two initial spaces may be deleted, but the │ │ │ │ number of spaces deleted from each line will be the same (so that you │ │ │ │ can have indenting work correctly, for example). The line must │ │ │ │ contain at least one non-whitespace character.

      • │ │ │ │

    • Those containing a single space followed by a single full stop │ │ │ │ character. These are rendered as blank lines. This is the only way │ │ │ │ @@ -831,30 +831,30 @@ │ │ │ │

      The first line of the field value (the part on the same line as │ │ │ │ Changes:) is always empty. The content of the field is expressed as │ │ │ │ continuation lines, with each line indented by at least one space. Blank │ │ │ │ lines must be represented by a line consisting only of a space and a │ │ │ │ full stop (.).

      │ │ │ │

      The value of this field is usually extracted from the │ │ │ │ debian/changelog file - see Debian changelog: debian/changelog.

      │ │ │ │ -

      Each version's change information should be preceded by a "title" line │ │ │ │ +

      Each version’s change information should be preceded by a “title” line │ │ │ │ giving at least the version, distribution(s) and urgency, in a │ │ │ │ human-readable way.

      │ │ │ │

      If data from several versions is being returned the entry for the most │ │ │ │ recent version should be returned first, and entries should be separated │ │ │ │ -by the representation of a blank line (the "title" line may also be │ │ │ │ +by the representation of a blank line (the “title” line may also be │ │ │ │ followed by the representation of a blank line).

      │ │ │ │
    • │ │ │ │
    │ │ │ │

    5.6.19. Binary

    │ │ │ │

    This folded field is a list of binary packages. Its syntax and meaning │ │ │ │ varies depending on the control file in which it appears.

    │ │ │ │

    When it appears in the .dsc file, it lists binary packages which a │ │ │ │ source package can produce, separated by commas [13]. The source │ │ │ │ package does not necessarily produce all of these binary packages for │ │ │ │ -every architecture. The source control file doesn't contain details of │ │ │ │ +every architecture. The source control file doesn’t contain details of │ │ │ │ which architectures are appropriate for which of the binary packages.

    │ │ │ │

    When it appears in a .changes file, it lists the names of the binary │ │ │ │ packages being uploaded, separated by whitespace (not commas). If no │ │ │ │ binary packages are being uploaded, this field will not be present.

    │ │ │ │
    │ │ │ │
    │ │ │ │

    5.6.20. Installed-Size

    │ │ │ │ @@ -964,21 +964,21 @@ │ │ │ │

    5.6.26. Version Control System (VCS) fields

    │ │ │ │

    Debian source packages are increasingly developed using VCSs. The │ │ │ │ purpose of the following fields is to indicate a publicly accessible │ │ │ │ repository where the Debian source package is developed.

    │ │ │ │
    │ │ │ │
    Vcs-Browser

    URL of a web interface for browsing the repository.

    │ │ │ │
    │ │ │ │ -
    Vcs-<type>

    The field name identifies the VCS. The field's value uses the version │ │ │ │ -control system's conventional syntax for describing repository │ │ │ │ +

    Vcs-<type>

    The field name identifies the VCS. The field’s value uses the version │ │ │ │ +control system’s conventional syntax for describing repository │ │ │ │ locations and should be sufficient to locate the repository used for │ │ │ │ packaging. Ideally, it also locates the branch used for development of │ │ │ │ new versions of the Debian package.

    │ │ │ │

    The following values for <type> are supported, with the corresponding │ │ │ │ -VCS indicated in parentheses if it isn't obvious:

    │ │ │ │ +VCS indicated in parentheses if it isn’t obvious:

    │ │ │ │
      │ │ │ │

    • Arch

      • │ │ │ │

    • Bzr (Bazaar)

      • │ │ │ │

    • Cvs (CVS)

      • │ │ │ │

    • Darcs

      • │ │ │ │

    • Git

      • │ │ │ │

    • Hg (Mercurial)

      • │ │ │ │ @@ -1075,17 +1075,17 @@ │ │ │ │

    • binary-targets (previous default): Declares that the │ │ │ │ package will need the root (or fakeroot) when either of the binary, │ │ │ │ binary-arch or binary-indep targets are called. This is how every │ │ │ │ tool behaved before this field was defined.

      • │ │ │ │

    • A space separated list of keywords described below. These keywords │ │ │ │ must always contain a forward slash, which sets them apart from the │ │ │ │ other possible values of Rules-Requires-Root. When this list │ │ │ │ -is provided, the builder must provide a "gain root command" (as │ │ │ │ +is provided, the builder must provide a “gain root command” (as │ │ │ │ defined in debian/rules and Rules-Requires-Root) or pretend that the value was set │ │ │ │ -to binary-targets, and both the builder and the package's │ │ │ │ +to binary-targets, and both the builder and the package’s │ │ │ │ debian/rules script must downgrade accordingly (see below).

      • │ │ │ │
    │ │ │ │
    │ │ │ │

    The default depends on the dpkg-build-api level (see dpkg-build-api(7)). │ │ │ │ If the dpkg-build-api level is undeclared, it is equivalent to level 0.

    │ │ │ │

    If the package builder supports the Rules-Requires-Root field and │ │ │ │ wants to enable the feature, then it must set the environment variable │ │ │ │ @@ -1133,15 +1133,15 @@ │ │ │ │