I rearchitectured the ddeb building, so that with debhelper dh_strip now only prepares the debian/pkgname-dbgsym/ package build dir, and diverts dh_gencontrol which adjusts the Version: and Depends: and then builds the .ddeb. This looks like a lot of code, but most of it (the whole argument parsing, determination of which binary packages to process, and building of the .ddebs) is a straight copy&paste of the already existing dh_strip. The only "new" code here is
# adjust ddeb version from deb, for dpkg-gencontrol's -v option
debversion=`grep '^Version:' $pkgdir/DEBIAN/control | cut -f2- -d\ `
sed -i "s/^Version: .*\$/Version: $debversion/; /^Depends:/ s/(= .*)/(= $debversion)/" $ddebpkgdir/DEBIAN/control
which addresses this bug, i. e. adjusts the ddeb versions for dpkg-gencontrol -v.
The existing test cases still all succeed, and the test suite runs during package build, so if the SRUed package builds we can already be fairly confident that there is no regression. Nevertheless, verifying that gcc now builds in a PPA with ddebs enabled should be done to verify the fix, and this test rebuild should also include at least systemd (many binaries with associated ddebs, debhelper) and binutils (manual pkg_create_dbgsym, no debhelper) to ensure no regressions.
But for the record, and "SRU regression potential": Nevertheless there is always the potential to break a package which previously built, of course. Or that we suddenly stop producing ddebs for a package with a weird debian/rules (e. g. using dh_strip but not dh_gencontrol).
I have this working in the packaging branch.
There already was a disabled test case "dhtest. versionoverride " for a package that spits out a different binary version. This commit enables this now, and adds an additional check that the binary versions of deb and ddeb are identical: bazaar. launchpad. net/~ubuntu- branches/ ubuntu/ vivid/pkg- create- dbgsym/ vivid/revision/ 234
http://
I also added an additional test for a package that calls pkg_create_dbgsym directly and does not use debhelper, like e. g. binutils does: bazaar. launchpad. net/~ubuntu- branches/ ubuntu/ vivid/pkg- create- dbgsym/ vivid/revision/ 235
http://
I rearchitectured the ddeb building, so that with debhelper dh_strip now only prepares the debian/ pkgname- dbgsym/ package build dir, and diverts dh_gencontrol which adjusts the Version: and Depends: and then builds the .ddeb. This looks like a lot of code, but most of it (the whole argument parsing, determination of which binary packages to process, and building of the .ddebs) is a straight copy&paste of the already existing dh_strip. The only "new" code here is
# adjust ddeb version from deb, for dpkg-gencontrol's -v option `grep '^Version:' $pkgdir/ DEBIAN/ control | cut -f2- -d\ ` DEBIAN/ control
debversion=
sed -i "s/^Version: .*\$/Version: $debversion/; /^Depends:/ s/(= .*)/(= $debversion)/" $ddebpkgdir/
which addresses this bug, i. e. adjusts the ddeb versions for dpkg-gencontrol -v.
The existing test cases still all succeed, and the test suite runs during package build, so if the SRUed package builds we can already be fairly confident that there is no regression. Nevertheless, verifying that gcc now builds in a PPA with ddebs enabled should be done to verify the fix, and this test rebuild should also include at least systemd (many binaries with associated ddebs, debhelper) and binutils (manual pkg_create_dbgsym, no debhelper) to ensure no regressions.
But for the record, and "SRU regression potential": Nevertheless there is always the potential to break a package which previously built, of course. Or that we suddenly stop producing ddebs for a package with a weird debian/rules (e. g. using dh_strip but not dh_gencontrol).