Provided by: libconfig-model-dpkg-perl_3.004_all bug

NAME

       Config::Model::models::Dpkg::Control::Binary - Configuration class Dpkg::Control::Binary

DESCRIPTION

       Configuration classes used by Config::Model

Elements

   Architecture
       If a program needs to specify an architecture specification string in some place, it should select one of
       the strings provided by dpkg-architecture -L. The strings are in the format os-arch, though the OS part
       is sometimes elided, as when the OS is Linux.  A package may specify an architecture wildcard.
       Architecture wildcards are in the format any (which matches every architecture), os-any, or any-cpu. For
       more details, see Debian policy <http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-
       arch-spec>  Mandatory. Type string.

   Multi-Arch
       This field is used to indicate how this package should behave on a multi-arch installations. This field
       should not be present in packages with the Architecture: all field.  Optional. Type enum. choice: 'same',
       'foreign', 'allowed'.

       Here are some explanations on the possible values:

       'allowed'
           allows  reverse-dependencies  to  indicate  in  their  Depends  field that they need a package from a
           foreign architecture, but has no effect otherwise.

       'foreign'
           the package is not co-installable with itself, but should be allowed to satisfy the dependency  of  a
           package of a different arch from itself.

       'same'
           the  package  is co-installable with itself, but it must not be used to satisfy the dependency of any
           package of a different architecture from itself.

   Section
        Optional. Type uniline.

       Note: Section is computed with '$source' and with:

       •   $source => "- - source Section"

   Priority
        Optional. Type enum. choice: 'required', 'important', 'standard', 'optional', 'extra'.

       Note: Priority is computed with '$source' and with:

       •   $source => "- - source Priority"

   Essential
        Optional. Type boolean.

   Depends - declares an absolute dependency.
       The Depends field should be used if the depended-on package is required  for  the  depending  package  to
       provide a significant amount of functionality. See also debian policy <https://www.debian.org/doc/debian-
       policy/ch-relationships.html>  Optional. Type list of uniline.

   Recommends - declares a strong, but not absolute, dependency.
       This  field  should  list  packages  that  would  be  found  together  with  this  one in all but unusual
       installations. See also  debian  policy  <https://www.debian.org/doc/debian-policy/ch-relationships.html>
       Optional. Type list of uniline.

   Suggests - declare that one package may be more useful with one or more others.
       Using this field tells the packaging system and the user that the listed packages are related to this one
       and  can  perhaps  enhance  its  usefulness,  but  that  installing  this  one  without them is perfectly
       reasonable.  See  also  debian  policy   <https://www.debian.org/doc/debian-policy/ch-relationships.html>
       Optional. Type list of uniline.

   Enhances - declare that a package can enhance the functionality of another package
       This  field  is  similar  to  Suggests  but works in the opposite direction. It is used to declare that a
       package   can   enhance   the   functionality   of   another   package.   See    also    debian    policy
       <https://www.debian.org/doc/debian-policy/ch-relationships.html>  Optional. Type list of uniline.

   Pre-Depends
       This  field  is  like  Depends,  except that it also forces dpkg to complete installation of the packages
       named before even starting the installation of the package which declares the pre-dependency.   See  also
       debian  policy  <https://www.debian.org/doc/debian-policy/ch-relationships.html>   Optional. Type list of
       uniline.

   Breaks
       When one binary package declares that it breaks another, dpkg will refuse  to  allow  the  package  which
       declares  Breaks  to  be  unpacked unless the broken package is deconfigured first, and it will refuse to
       allow the broken package to be reconfigured. See also debian  policy  <https://www.debian.org/doc/debian-
       policy/ch-relationships.html>  Optional. Type list of uniline.

   Conflicts
       When  one  binary  package  declares a conflict with another using a Conflicts field, dpkg will refuse to
       allow them to be unpacked on the system at the same time. This is a  stronger  restriction  than  Breaks,
       which  prevents  the broken package from being configured while the breaking package is in the "Unpacked"
       state  but  allows  both  packages  to  be  unpacked  at  the  same  time.   See   also   debian   policy
       <https://www.debian.org/doc/debian-policy/ch-relationships.html>  Optional. Type list of uniline.

   Provides
       declare  the  functionality brought by this package. Be sure to read the chapter about virtual package in
       debian  policy   <https://www.debian.org/doc/debian-policy/ch-relationships.html>   before   using   this
       parameter.  Optional. Type list of uniline.

   Replaces
       declare  that  this package should overwrite files in certain other packages, or completely replace other
       packages. Be sure to read the section 7.6 of debian policy  <https://www.debian.org/doc/debian-policy/ch-
       relationships.html> before using this parameter.  Optional. Type list of uniline.

   Built-Using - Additional source packages used to build the binary
       Some  binary  packages  incorporate parts of other packages when built but do not have to depend on those
       packages. Examples include linking with static  libraries  or  incorporating  source  code  from  another
       package  during  the build. In this case, the source packages of those other packages are a required part
       of the complete source (the binary package is not reproducible without them).

       A Built-Using field must list the corresponding source package for any such binary  package  incorporated
       during  the  build,  including  an "exactly equal" ("=") version relation on the version that was used to
       build that binary package.

       A package using the source code from the gcc-4.6-source binary package  built  from  the  gcc-4.6  source
       package would have this field in its control file:

            Built-Using: gcc-4.6 (= 4.6.0-11)

       A package including binaries from grub2 and loadlin would have this field in its control file:

            Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) I< Optional. Type list of uniline.  >

   Package-Type - The type of the package, if not a regular Debian one
       If  this  field  is present, the package is not a regular Debian package, but either a udeb generated for
       the Debian installer or a tdeb containing translated  debconf  strings.   Optional.  Type  enum.  choice:
       'tdeb', 'udeb'.

       Note: Package-Type is migrated with '$xc' and with:

       •   $xc => "- XC-Package-Type"

   XC-Package-Type - The type of the package, if not a regular Debian one
       If  this  field  is present, the package is not a regular Debian package, but either a udeb generated for
       the Debian installer or a tdeb containing translated debconf strings. Deprecated   Optional.  Type  enum.
       choice: 'tdeb', 'udeb'.

   Synopsis
        Mandatory. Type uniline.

   Description
        Mandatory. Type string.

   Homepage
        Optional. Type uniline.

   XB-Python-Version
       Deprecated  Optional. Type uniline.

   XB-Ruby-Versions
       indicate the versions of the interpreter supported by the library.  Optional. Type uniline.

   Build-Profiles
       Build-Profiles specifies the condition for which that binary package does or does not build.

       This  is expressed as a list of lists of (optionally negated) profile names, forming a conjunctive normal
       form expression in the same syntax as in the Build-Depends field.

       For instance:

           Build-Profiles: <!cross> <!nocheck>

       See <https://wiki.debian.org/BuildProfileSpec#The_Build-Profiles_field> for more details.  Optional. Type
       uniline.

SEE ALSO

       •   cme

AUTHOR

       Dominique Dumont

COPYRIGHT

       2010,2011 Dominique Dumont

LICENSE

       LGPL2

perl v5.38.2                                       2024-03-03             Config::Model::...Control::Binary(3pm)