Maintain package version mapping

[briandealwis]

#276 and #214 request branding the distroless/java images with metadata about the underlying language runtime version. Unfortunately the package information is not available when building the image: all that is available is the actual .deb file.

distroless/java/BUILD

Lines 12 to 17 in 55b0eb2

	[container_image(
	name = rule_name,
	base = "//cc" if (not ("debug" in rule_name)) else "//cc:debug",
	debs = [
	packages["zlib1g"],
	packages[jre_deb],

Rather than try to extract the .deb's control.tar.gz and its control file, this PR changes the package_manager to also record a package-to-version mapping (versions) that is written out with the @package_bundle//file:packages.bzl.

The resulting packages.bzl file now looks like:

packages = {"libgcc1": "@package_bundle//file:bGliZ2NjMQ==.deb", "libgomp1": "@package_bundle//file:bGliZ29tcDE=.deb", ... }
versions = {"libgcc1": "1:6.3.0-18+deb9u1", "libgomp1": "6.3.0-18+deb9u1", ...}

With this change, the java/BUILD can now pull in the versions information and use versions[jre_deb] to annotate the generated images. See my proposed branch for an example.

Still outstanding: I'm not sure how the package_manager_tools bundle is updated with package_manager/package_manager.bzl.

[chanseokoh]

Still outstanding: I'm not sure how the package_manager_tools bundle is updated with package_manager/package_manager.bzl.

dpkg_parser.par is auto-uploaded whenever a PR is merged. For example, the latest commit from git log is

commit 55b0eb29ae8228e59ec14b02ca6b904c20340f06 (HEAD -> master, origin/master, origin/HEAD)
Author: Sharif Elgamal <[email protected]>
Date:   Wed Jan 30 17:32:41 2019 -0800

and we already have the binary built from it: https://storage.googleapis.com/distroless/package_manager_tools/55b0eb29ae8228e59ec14b02ca6b904c20340f06/dpkg_parser.par

[briandealwis]

@sharifelgamal is it safe to merge this patch to distroless/package_manager? Is there anything else that needs to be done for it to be picked up?

[chanseokoh]

I think this is good to go and safe. Even if the new dpkg_parser.par breaks things if used, we won't be picking up the new one, because we are fetching a specific dpkg_parser.par built in the past.