ubuntu-pro-client-l10n translations are stripped

@Grant: There is a variable which disables pkgbinarymangler completely, and which can be set in debian/rules:

export NO_PKG_MANGLE=1

It's used by some other packages for this very purpose, and in this case it would mean that we could avoid all those pkgbinarymangler uploads.

Does pkgbinarymangler do anything important with ubuntu-advantage-tools (besides translation stripping)? If not, I think using the NO_PKG_MANGLE variable instead is worth considering.

Hi Gunnar, that's a great suggestion!

I've been using NO_PKG_MANGLE=1 for testing, but was worried about what else we'd miss if pkgbinarymangler was completely disabled. I believe it is at least stripping debug symbols from our apt-hook binary and also trimming our changelog on older releases.

But like you say, it would be nice to avoid all these uploads. I'll do some tests today to see exactly what the impact will be. If it is small enough then we can probably just use NO_PKG_MANGLE=1 and save us some trouble :)

I ran some tests and this is what I found:

I wasn't exactly right in thinking pkgbinarymangler is stripping debug symbols from our binary. It is dh_strip that is doing that, but on xenial, dh_strip honors the NO_PKG_MANGLE environment variable. However in this case the difference in resulting binary size is negligible (<1kb).

I found two things that pkgbinarymangler is doing for us:

1. it truncates the ubuntu-advantage-tools changelog to the latest 10 entries.
2. it links the ubuntu-advantage-pro changelog to the ubuntu-advantage-tools changelog.

So by setting NO_PKG_MANGLE=1 we end up with a u-a-t binary package that is 20kb larger (all from the changelog) and an ubuntu-advantage-pro binary package that is also 20kb larger (also all from the changelog since it is neither truncated nor linked). ubuntu-advantage-pro is only installed on Cloud Pro images, though, so is less important than ubuntu-advantage-tools which is everywhere.

It feels a bit wrong to ship a 20kb changelog when its not necessary, but maybe it's okay.

I think we should get an SRU team decision to decide which is preferable:

A. NO_PKG_MANGLE=1 and 20kb u-a-t changelog for x, b, f, j, l
B. SRU the striptranslations.blacklist update to x, b, f, j, l

Speaking for myself as a member of the SRU team, and not the SRU team as a whole:

It seems to me that since pkgbinarymangler is designed to do multiple things, some of which we have no reason to disable, we should aim to disable just the translation handling since that's exactly what we want to do. And the package has a mechanism to do that so we should use it. Even if a little unwieldy by requiring a pkgbinarymangler upload, using this mechanism seems like it would be relatively risk-free in an SRU because it is very specifically targetted. Even if it does potentially impact every build, its behaviour should be able to be fairly easily checked. We could verify that its behaviour hasn't changed against an unrelated package during SRU verification easily and confidently enough. Using NO_PKG_MANGLE sounds like it has other side effects that might have more implications that need consideration and therefore more risk of missing something.

For the development release, perhaps a finer-grained control in pkgbinarymangler that can be operated from the build of a package itself rather than changing pkgbinarymangler would be appropriate. But for an SRU I think using striptranslations.blacklist seems like the minimally impactful way to do it.

Thanks Robie!

We'll stick with the plan to update striptranslations.blacklist via pkgbinarymangler SRUs then.

Since this is tightly coupled to the upcoming u-a-t release, we'll handle the uploads as part of the u-a-t release process.