summaryrefslogtreecommitdiff
path: root/scripts/Dpkg/Control/FieldsCore.pm
AgeCommit message (Collapse)AuthorFilesLines
2019-02-23dpkg-genbuildinfo: Add support for a new Build-Tainted-By fieldGuillem Jover1-1/+6
This field will contain a list of tainting reason tags, which can denote that the current build has potentially been broken. Suggested-by: Alexander E. Patrakov <patrakov@gmail.com>
2017-10-12scripts: Add support for source package Description and substvarsGuillem Jover1-4/+4
We support a new source package Description field in debian/control that will be copied into the .dsc file. The field will also be used to initialize the new source:Synopsis and source:Extended-Description substvars that will be available when generating the DEBIAN/control and .changes files. Closes: #555743
2017-10-12dpkg-genbuildinfo: Add support for new Build-Kernel-Version fieldGuillem Jover1-2/+6
Packages intended to be built in a generic way must never rely on the currently running kernel on the build system (an exception could be an optimization rebuild using the current system as the reference baseline). But to be able to detect when a package might not be reproducible due to varying kernel information it is still useful to be able to record this information. Although that information can be very sensitive. When the builder has explicitly enabled the Build-Kernel-Version field with the new dpkg-genbuildinfo --always-include-kernel option, it will get included in the generated .buildinfo file. Closes: #873937
2017-09-24dpkg-buildpackage: Add support for rootless buildsGuillem Jover1-0/+5
Implement the rootless-builds specification, by honoring the Rules-Requires-Root (R³) field.
2017-09-24Dpkg::Control::FieldsCore: Do not execute code at import timeGuillem Jover1-11/+21
2017-09-24Dpkg::Control::FieldsCore: Remove dependency on Dpkg::ChecksumsGuillem Jover1-19/+39
2017-09-24Dpkg::Control::FieldsCore: Switch internal field name handling to lowercaseGuillem Jover1-157/+271
Change field name handling to always work with them as lowercase, add a new name key to store the capitalized form, and use that when we need to return that form instead of computing it on every instance.
2017-09-24Dpkg::Control::FieldsCore: Complete field order for all control typesGuillem Jover1-3/+8
The CTRL_PKG_DEB and CTRL_FILE_STATUS types were missing some allowed fields in their order list, which meant that the field information was not coherent.
2017-09-24Dpkg::Control::FieldsCore: Mark all missing CTRL_INDEX_* fields as allowedGuillem Jover1-6/+6
2017-01-29Revert "dpkg-source: Generate Testsuite-Restrictions fields from test ↵Guillem Jover1-6/+1
restrictions" This reverts commit 9899bdcf9bde76d969b124abf0a898fcbb202c70. This change is contentious and should have been discussed more widely. Given that this has been live only for a couple of days, the impact should be minimal, but still something to take into account once and if this gets reintroduced, in the same or different form and shape. Closes: #852820
2017-01-25dpkg-source: Generate Testsuite-Restrictions fields from test restrictionsGuillem Jover1-1/+6
This information is currently only available in the Restrictions field in the debian/tests/control file. When dispatching tests, it might be inconvenient to have to download and unpack the source package beforehand. Let's expose this via the .dsc in a similar way we do for the Testsuite-Triggers field. Closes: #847926 Based-on-patch-by: Iain Lane <laney@debian.org>
2017-01-23man, Dpkg::Control::FieldsCore: Add new Auto-Built-Package fieldGuillem Jover1-1/+5
This field is used to distinguish packages that have been automatically injected by some build tool, and are not present in the debian/control file.
2016-11-16dpkg-genbuildinfo: Add Build-Date fieldGuillem Jover1-1/+4
This records the time the build happened. This might be useful when there is a need to track down problems caused by external time-based events not visible from inside the build system. Things like hardware, software deployment or other such failures.
2016-11-03scripts: Add support for .buildinfo filesGuillem Jover1-6/+35
The .buildinfo files are a new type of control files, similar to the .changes files, meant to describe the environment of a build and its artifacts. They are meant to be added to the Debian archive to allow independent parties to reproduce a build and verify the result. Specifications for .buildinfo are available at: <https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification> This patch adds support for .buildinfo files in Dpkg::Control, adds new .buildinfo fields to Dpkg::Control::Fields, a new builtin-system-build-paths Dpkg::Vendor hook, and adds a new script named dpkg-genbuildinfo, that will now be called by dpkg-buildpackage before generating the .changes file. [ntyni@debian.org: small changes. ] Closes: #138409 Based-on-patch-by: Jérémy Bobbio <lunar@debian.org> Signed-off-by: Guillem Jover <guillem@debian.org>
2016-07-03man, perl: Remove most AUTHOR sectionsGuillem Jover1-4/+0
These are strongly discouraged by the man-pages project, because they are redundant with the copyright notices, and tend to get out-of-sync. In addition their format is inconsitent. Just remove them in the same way we did for man pages in the past.
2016-07-03dpkg-source: Generate Testsuite-Triggers field from test dependenciesGuillem Jover1-2/+6
Sometimes autopkgtests regress due to change in a package which is only a test dependency (Depends: in debian/tests/control), not a build or binary one. It is useful to trigger a test if such a test dependency changes. Record the union of all test dependency packages in a new Testsuite-Triggers field in the .dsc, so that they will be recorded in the Sources package index. Ignore versions and flatten OR dependencies as they are not interesting for determining reverse test dependencies and should not be (ab)used for replacing debian/tests/control parsing. Closes: #779559 LP: #1491145 Based-on-patch-by: Martin Pitt <martin.pitt@ubuntu.com> Signed-off-by: Guillem Jover <guillem@debian.org>
2016-07-03Dpkg::Control: Add new autopkgtest control files supportGuillem Jover1-1/+23
Add new CTRL_TESTS control types, new Dpkg::Control::Tests and Dpkg::Control::Tests::Entry modules, add support for the fields that can appear on these control files, and update Dpkg::Index to handle them as well. [niels@thykier.net: Fix logic inversion. ]
2016-07-03Dpkg::Changelog: Add new Timestamp field to outputGuillem Jover1-1/+4
This field contains the date of the entry in seconds since the epoch. To make it easier to retrieve the date in a format that is easier to handle.
2016-07-03scripts: Fix typos in PODGuillem Jover1-1/+1
2016-01-26Dpkg::Control: Add new CTRL_COPYRIGHT control block typesGuillem Jover1-3/+32
The types are CTRL_COPYRIGHT_HEADER, CTRL_COPYRIGHT_FILES and CTRL_COPYRIGHT_LICENSE. These describe the different control blocks of a machine readable debian/copyright file, as specified in <https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/>.
2016-01-26Dpkg::Control: Add new CTRL_REPO_RELEASE control block typeGuillem Jover1-4/+31
2015-12-25Dpkg::Control::FieldsCore: Add support for Build-Essential fieldGuillem Jover1-0/+3
Closes: #806315
2015-07-29Dpkg::Control::FieldsCore: Allow the Maintainer field in CTRL_FILE_STATUSGuillem Jover1-1/+1
This field is part of the status field.
2015-07-28Dpkg: Remove my keyword from POD function prototypesGuillem Jover1-1/+1
2015-05-18scripts: Document dpkg version when module versions got bumpedGuillem Jover1-1/+1
This has two purposes, first it will make it easier to know if the module version needs to be bumped for the current development release, and second it will make it easier for users to know how "old" that module version is, and to which dpkg series and specific version it corresponds to.
2015-03-30perl: Rework use and exporter declarationsGuillem Jover1-9/+20
Place 'use' strict and warnings first, then Exporter 'our' declarations, then Test module imports, then system module imports, then Dpkg module imports, then 'use' parent and overload pragmas, separated by a blank line for each block. Split each exported symbol declaration into its own line to ease modifications.
2015-01-28Dpkg: Use shift instead of @_ on single argument unpackingGuillem Jover1-1/+1
2015-01-28scripts: Rename and deprecate _g function with g_Guillem Jover1-2/+2
The old function name was inconsistent with the other gettext family of short aliases which has already caused some code typos, and functions starting with underscore are considered by convention private in Perl.
2014-10-12scripts: Document all public module versions in a CHANGES sectionGuillem Jover1-0/+6
This makes it clear what is the current version of the module, and that it is a public interface.
2014-10-06scripts: Unpack arguments instead of accessing @_ directlyGuillem Jover1-3/+6
Addresses Subroutines::RequireArgUnpacking. Warned-by: perlcritic
2014-04-21dpkg-source: Add arch and profile information to Package-List fieldGuillem Jover1-0/+4
Add two new optional values to the Packages-List field, with architecture and build-profiles information. These values have the form «name=value1,value2», and might appear in any order after the mandatory values. This allows to run bootstrapping analysis over the Sources package indices. Requested-by: Johannes Schauer <j.schauer@email.de> Suggested-by: Raphaël Hertzog <hertzog@debian.org>
2014-01-15Dpkg::Control::FieldsCore: Add support for Testsuite source fieldGuillem Jover1-1/+5
This field is used to specify what type of test suite is present in the source package. The values within are comma separated.
2013-12-07Use https:// URLs instead of http:// when possibleGuillem Jover1-1/+1
2013-12-05Add experimental build profiles supportGuillem Jover1-3/+8
This adds the basic infrastructure support for a new class of generic build-time dependency restrictions, and in particular implements the specific build profiles, which will allow to cull build dependencies depending on the profile being used. There's several things this can be used for, like new port bootstrapping, reduced package builds, and similar. In the future other kinds of restrictions could be added as the build profiles are namespaced with “profile.”. An example field could be: Build-Depends: exotic-compiler, libneeded-dev, tool-tiny, tool-huge (>= 1.0) [linux-any] <!profile.embedded !profile.bootstrap> or even stuff like: Depends: net-tools <profile.network>, plugin-curl <!profile.no-plugins> The generated binary packages and .changes files will get a new Built-For-Profiles field containing the active profiles during the build. In addition the build profile can be selected using the environment variable DEB_BUILD_PROFILES, with space separated values, such as: DEB_BUILD_PROFILES="embedded bootstrap" The management and possible registration in the profile namespace is currently out of scope in dpkg, this should probably be handled by a distribution specific process. See draft <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>. Closes: #661538 Based-on-patch-by: Patrick "P. J." McDermott <pjm@nac.net> Based-on-patch-by: Wookey <wookey@debian.org> Based-on-patch-by: Johannes Schauer <j.schauer@email.de> Signed-off-by: Guillem Jover <guillem@debian.org>
2013-10-27doc: Write hyphen instead of dash when we mean the ‘-’ characterGuillem Jover1-1/+1
2013-07-26Dpkg::Control::FieldsCore: Add field value separation informationGuillem Jover1-2/+58
This information helps when needing to handle the field values semantically.
2013-07-26Dpkg::Control::Fields: Detangle Dpkg::VendorGuillem Jover1-0/+599
Move the bulk of the code into two new vendor-neutral Core sub-modules Dpkg::Control::FieldsCore and Dpkg::Control::HashCore, that get imported by Dpkg::Control::Fields and Dpkg::Control::Hash respectively; so that modules like Dpkg::Control::HashCore can make use of Dpkg::Control::FieldsCore w/o getting into a circular import due to Dpkg::Vendor previously using Dpkg::Control::Hash. The old dependency graph would have been: Control::Hash → Control::Fields ↑ ↓ Vendor The new one would be: Control::Hash → Control::Fields ↓ ↓ ↓ ↓ Vendor ↓ ↓ ↓ ↓ Control::HashCore → Control::FieldsCore
generated by cgit v1.2.3 (git 2.39.1) at 2025-05-11 15:41:15 +0000