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