Package: dpkg
Version: 1.19.4
When parsing "* Build-Depends-Package: " in a symbols file,
dpkg-shlibdeps currently does not appear to support multiple dev
packages listed in this field. This could be useful in cases such the
following:
* Source package "foo" provides "libfoo-c-dev" and
"libfoo-fortran-dev" binary packages with no overlap, along with a
"libfoo-dev" metapackage that depends on both. (This might happen if
a source package transitions from building a single "libfoo-dev"
binary package to building a split set of -dev binary packages, or it
might be done at first release for simple convenience).
* Source package "bar" may have a build-dep that could be satisfied by
only the "libfoo-c-dev" package, while source package "baz" may have a
build-dep that really does need the full "libfoo-dev" package set (or
perhaps "baz" only happens to know about the original, combined
"libfoo-dev" package).
In the current dpkg code, both "bar" and "baz" source packages could
only get accurate dpkg-shlibdeps info if they both specified
"Build-Depends: libfoo-dev (>=[ver])", and source package "foo"
included "* Build-Depends-Package: libfoo-dev" in all package symbols
files. I see no mechanism to allow either "libfoo-c-dev" or
"libfoo-dev" to trigger shlibdeps dependency versioning in this
scenario.
It would be fairly simple to support such a mechanism using one of two
approaches:
1) Extend "* Build-Depends-Package:" to understand multiple (space or
comma-delimited) package names in this field (see attached diff for
PoC code).
2) Add a new meta-info token (such as plural "*
Build-Depends-Packages:") to support the above syntax, without
modifying the existing understanding of singular
"Build-Depends-Package" (this would be trivially different from PoC
code).
Even though my initial PoC took the first approach, I'm favoring the
second approach, because it avoids breaking backwards compatibility.
With the first approach, any package using the new syntax in its
symbols files would completely lose this functionality on dpkg
releases that don't understand the new syntax (unmodded dpkg doesn't
completely fail, but it appears to simply not match anything in
"Build-Depends-Package" if it lists multiple packages). The second
approach allows packagers to take advantage of the new meta-info
without giving up the original meta-info functionality on older dpkg.
--
Frank Schaefer
"If a server crashes in a server farm and no one pings it, does it
still cost four figures to fix?"
--- dpkg-shlibdeps.orig 2019-04-08 12:55:28.649166818 -0500
+++ dpkg-shlibdeps 2019-04-08 12:54:27.777685461 -0500
@@ -435,18 +435,22 @@
foreach my $soname (@sonames) {
# Adjust minimal version of dependencies with information
# extracted from build-dependencies
- my $dev_pkg = $symfile->get_field($soname, 'Build-Depends-Package');
- if (defined $dev_pkg) {
- debug(1, "Updating dependencies of $soname with build-dependencies");
- my $minver = get_min_version_from_deps($build_deps, $dev_pkg);
- if (defined $minver) {
- foreach my $dep ($symfile->get_dependencies($soname)) {
- update_dependency_version($dep, $minver, 1);
- debug(1, " Minimal version of $dep updated with $minver");
+ my $dev_pkg_list = $symfile->get_field($soname, 'Build-Depends-Package');
+ if (defined $dev_pkg_list) {
+ foreach my $dev_pkg (split(/[,\s]+/, $dev_pkg_list)) {
+ if (defined $dev_pkg) {
+ debug(1, "Updating dependencies of $soname with build-dependencies");
+ my $minver = get_min_version_from_deps($build_deps, $dev_pkg);
+ if (defined $minver) {
+ foreach my $dep ($symfile->get_dependencies($soname)) {
+ update_dependency_version($dep, $minver, 1);
+ debug(1, " Minimal version of $dep updated with $minver");
+ }
+ } else {
+ debug(1, " No minimal version found in $dev_pkg build-dependency");
+ }
}
- } else {
- debug(1, " No minimal version found in $dev_pkg build-dependency");
- }
+ }
}
# Warn about un-NEEDED libraries
