RM pkg-create-dbgsym -> adjust the way to create dbgsym packages like Debian does

I'm currently looking into using debhelper's dbgsym generation instead of pkg-create-dbgsym. This requires some modifications, in particular:

  * Naming the dbgsym packages .ddeb instead of .deb (as LP cannot deal with .deb right now)
  * Reading /CurrentlyBuilding to determine whether or not build dbgsyms.

It would be nice if Launchpad builders could move away from /CurrentlyBuilding and instead set ENABLE_DBGSYM=0 if debug symbols should *not* be built; for the default, it can either not set it at all or set ENABLE_DBGSYM=auto. This would then get rid of the /CurrentlyBuilding parsing logic in dh_strip.

A few weeks back I was experimenting with two approaches, but now I don't seem to find enough time to get back to this. So for posterity, this is the naïve approach that just sets -DPackage-Type=ddeb. However, dpkg does not actually respect that for this case, so this has no effect. Adam said that he'd like to fix this in dpkg proper though. (Note that this patch does not do any parsing of /CurrentlyBuilding which we will need for some transition period).

This is the more invasive approach which by and large works with current dpkg. The main inconvenience is that by specifying the file name instead of output dir debhelper now has to divine the full file name and thus parse DEBIAN/control.

IIRC this patch does not yet work, but it should be close. But again it also does not yet parse /CurrentlyBuilding for determining whether or not to enable ddebs, until Launchpad sets DH_BUILD_DDEBS.

We'll probably have to keep /CurrentlyBuilding around for a while. It's used by both pkgbinarymangler and pkg-create-dbgsym (to my knowledge; if you know of more, please list them here), and those would have to be updated in all series, *including* the -security pockets, before we could drop /CurrentlyBuilding entirely. Still, it's certainly straightforward to set additional environment variables. I agree that it would be nice to go that way, as the current approach is pretty weird.

Do you have a proposal for what we could do to supersede the use of /CurrentlyBuilding in pkgbinarymangler?

In comment #1, you suggest setting ENABLE_DBGSYM; in comment #3, you suggest setting DH_BUILD_DDEBS. Which is preferable? As far as I can see neither is supported by upstream debhelper (ENABLE_DBGSYM is a key in the internal %dh hash, not an environment variable).

Sorry about the env var confusion -- in fact $ENABLE_DBGSYM is an internal variable in dh_strip, so that's definitively wrong. $DH_BUILD_DDEBS is still present in our version of debhelper:

  $dh{ENABLE_DBGSYM} = 0 if not $ENV{'DH_BUILD_DDEBS'};

but got dropped in Debian, so let's not use that either. The manpage documents

        The automatic creation of debug symbol packages can also be prevented by adding noautodbgsym to the DEB_BUILD_OPTIONS
       environment variable. However, dh_strip will still add debuglinks to ELF binaries when this flag is set. This is to ensure
       that the regular deb package will be identical with and without this flag (assuming it is otherwise "bit-for-bit"
       reproducible).

So let's use that then?

> We'll probably have to keep /CurrentlyBuilding around for a while.

Yes, indeed. At some point we might consider SRUing the testing of DEB_BUILD_OPTIONS to stable pkgbinarymanglers/pkg-create-dbgsyms, but let's first let this bake a while. Until then our debhelper should test /CurrentlyBuilding too.

Not sure if this is still relevant, but ...

If you are going to make debhelper use ".ddeb" rather than ".deb" for dbgsym packages (and dpkg doesn't DTRT), I strongly recommend relying on the "build_and_rename_deb" sub in dh_builddeb rather than computing the filename yourself. Otherwise, "dh_gencontrol -- -V $(VERSION)" is going to be needlessly painful (like it was with udebs).

launchpad-buildd (142) trusty; urgency=medium

  * lpbuildd.binarypackage: Pass DEB_BUILD_OPTIONS=noautodbgsym if we have
    not been told to build debug symbols (LP: #1623256).
  * debian/upgrade-config, lpbuildd.slave: Drop compatibility with ancient
    pre-lucid versions of python-apt.
  * lpbuildd.pottery.intltool: Remove unused and Python-3-unfriendly
    string/file conditional from ConfigFile.__init__.
  * Use Python-3-compatible forms of "print" and "except".
  * buildsnap: Set SNAPCRAFT_SETUP_CORE=1 during pull phase so that
    snapcraft will fetch and unpack the core snap for classic confinement
    when necessary (LP: #1650946).

 -- Colin Watson <email address hidden> Fri, 10 Feb 2017 14:53:43 +0000

The attachment "(concept patch) set Package-Type=ddeb" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

This bug was fixed in the package dpkg - 1.18.23ubuntu4

---------------
dpkg (1.18.23ubuntu4) artful; urgency=medium

  * dpkg-genchanges: Add buildinfo files to changes now that LP is fixed.

 -- Adam Conrad <email address hidden> Fri, 21 Apr 2017 12:00:18 -0600

This bug was fixed in the package debhelper - 10.2.5ubuntu2

---------------
debhelper (10.2.5ubuntu2) artful; urgency=medium

  * Generate ddebs from debhelper instead of pkg-create-dbgsym (LP: #1623256)
    - Make debhelper Conflict/Replace pkg-create-dbgsym to force it off.
    - Revert the revert that disabled debhelper's attempts to do dbgsyms.
    - Mirror udeb code in dh_builddeb to allow us to alter file extension.
    - Set dbgsym Package-Type to ddeb to get correct debian/files output.
    - Depend on dpkg-dev (>= 1.18.23ubuntu3) so the above works correctly.

 -- Adam Conrad <email address hidden> Thu, 20 Apr 2017 20:19:06 -0600

Now, I think we have already stopped using pkg-create-dbgsym wince some months... shouldn't this package go away now?

Hurray!