Config...Binary(3pm)

📦

version 3.026 · 6 versions

💖 Config...Binary(3pm) 💖

okay bestie, sit DOWN 🫶 this is a User Contributed Perl Documentation page for Config...Binary(3pm), and it is a LOT. Grab your boba, we're going through every single field together, no skipping, no cap 💅✨

🎀 NAME 🎀

Config::Model::models::Dpkg::Control::Binary — the Configuration class. That's it, that's the name, periodt 👑

🧚 DESCRIPTION 🧚

These are the Configuration classes used by Config::Model. Cute, right? That's the summary. Everything below is the elements, and girl there are a LOT of them 🌈

🦋 Elements 🦋

🏗️ Architecture

So if a program needs to drop an architecture specification string somewhere, it should pick one of the strings that dpkg-architecture -L hands out. Those strings are formatted os-arch, though ngl the OS part is sometimes elided — like when the OS is Linux. A package may also specify an architecture wildcard, and those come in the format any (which matches literally every architecture, she's versatile 💅), os-any, or any-cpu. For more details, see Debian policy at http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-spec 📖

Mandatory. Type: string.

🌐 Multi-Arch

This field tells the world how this package should behave on multi-arch installations. Real talk though: this field should not be present in packages that have the Architecture: all field. Like, don't even try it. She said no 🚫

Optional. Type: enum. Choice: 'no', 'same', 'foreign', 'allowed'.

Here's the tea on all the possible values:

'allowed' — lets reverse-dependencies say in their Depends field that they need a package from a foreign architecture, but otherwise? No effect at all. Support system only 🫶
'foreign' — the package is not co-installable with itself, but it should be allowed to satisfy the dependency of a package of a different arch from itself.
'no' — the package is not co-installable AND it must not be used to satisfy the dependency of any package of another architecture than its own. Hard no 💀
'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 — The package is essential as defined by Debian Policy

The package is an essential package as defined by Debian Policy. The following rules apply to it, and these are not vibes, these are LAW:

Essential packages are considered essential for the system to work. The packaging system (APT and dpkg) will warn you and refuse to uninstall them without some very insistent force options. She will NOT go quietly 😤
Other packages are not required to declare explicit dependencies on essential packages as a side-effect of the above — except as needed to ensure that the given essential package is upgraded to a given minimum version.
Once installed, essential packages must function at all times, no matter where dpkg is in its installation or upgrade process. During bootstrapping or installation, this requirement is relaxed. Okay that one's a little chill at least 😮‍💨

Note: if you're looking for a way to prevent accidental uninstallation, please consider using "Protected: yes" instead.

Optional. Type: boolean.

🚧 XB-Important — Obsolete and incomplete variant of the Protected field

This is the prototype field that led to Protected — which should be used instead. It makes apt (but not dpkg, she said what she said) require extra confirmation before removing the package. Deprecated. Optional. Type: boolean.

upstream_default value:

no

🔒 Protected — Mark as Protected (uninstall protection)

Declare this package as a system critical package. When the field is set to "yes", both apt and dpkg will assume that removing the package may break the system. As a consequence, they'll require extra confirmation (or "force" options) before removing the package. This field basically provides "uninstall" protection similar to that of "Essential" packages — without the other benefits and requirements that come with "Essential" packages. In a Debian context, this field is generally applicable to packages like bootloaders, kernels, and other packages that might be necessary for booting the system. She's the bodyguard 🫡

Optional. Type: boolean.

upstream_default value:

no

Here's the breakdown of the possible values:

'no' — The package is a regular package. This is the default and recommended. ✨
'yes' — The package is protected and attempts to uninstall it will cause strong warnings to the user that they might be breaking the system. 😭

Note: Protected is migrated with '$xbi' and with:

$xbi => "- XB-Important"

🧲 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 at https://www.debian.org/doc/debian-policy/ch-relationships.html 📖