| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The .changes file describes an upload, and its Binary and Description
fields should contain (as documented) only references to the packages
being uploaded.
In case of a source-only upload, the Binary and Description fields
should be empty.
Closes: #818618
|
|
The .buildinfo file also makes sense on source-only uploads, because it is
still a build. And more so when we have done a full build, but filtered the
changes to only include the sources in the upload.
In any case, this was the intended behavior from the beginning.
Closes: #846164
|
|
Using undeterministic filenames based on the buildinfo-id produces ugly
looking filenames, which get left behind when rebuilding the same source
multiple times as they vary by date.
There's really no great point in using unique filenames as they will end
up with different contents depending on the builder.
|
|
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>
|
|
Taken from dpkg-tests functional test suite.
|
