Track ZFSBootMenu versions in-image with /etc/os-release

[ahesford]

I still need to test this and make sure build containers do the right thing, but here's the concept.

I'm open to suggestions on the template rendering.

[zdykstra]

Detecting if the Makefile is being run from a git checkout and replacing the version in generate-zbm (and subsequently in zbm-release) with a commit SHA would be nice to add in to this as well.

[classabbyamp]

maybe also add:

• VERSION_ID
• BUILD_ID (date of image build and maybe git hash if available?)
• SUPPORT_URL and BUG_REPORT_URL?
• ANSI_COLOR (maybe something based on the logo)

[ahesford]

Added BUILD_ID, SUPPORT_URL and BUG_REPORT_URL. I'm not sure VERSION_ID has any particular meaning, and I don't think we should encourage r/unixporn snapshots by adding ANSI_COLOR.

[ahesford]

I guess this mostly captures my vision for version handling in-repo. Comments welcome.

The alternative to committing +dev tags is to drop version handling from bin/generate-zbm and zfsbootmenu/zbm-release altogether, and just require that releng/version.sh write the proper version before the contents are meaningful (e.g., record some template placeholder like @@VERSION@@ in bin/generate-zbm and zfsbootmenu/zbm-release). However, that seems undesirable because:

1. Attempting to use bin/generate-zbm or zfsbootmenu/zbm-release from a live repo will result in nonsense versioning, whereas comitting something like ${version}+dev ensures that the contents of the files is actually meaningful at all times.
2. GitHub source archives would be useless, because we wouldn't have a way to read the version outside of a git repository. Instead, we'd have to do something like render some VERSION file (or the contents of bin/generate-zbm and zfsbootmenu/zbm-release) and produce a release tarball as a separate asset. At this point, we might as well just take steps to ensure that the version in these files is always at least somewhat meaningful.

make zbm-release should be idempotent when acting on GitHub release tarballs, so I figure adding it as a dependency of the core target is a reasonable approach to making sure the version on installed packages is always the most informative that we can discern.

[ahesford]

Turns out dracut creates its own /usr/lib/os-release and symlinks /etc/os-release to it, clobbering the one created by the ZBM module. As a workaround, I install /etc/zbm-release and symlink /etc/os-release to that, which will still be clobbered by dracut but will leave /etc/zbm-release for users to see.

I've also added some support in the container image and zbm-builder.sh for using the new versioning script. (Note that build containers do not include git by default. To get a version other than what is already recorded in the repository, it is necessary to do, e.g., zbm-builder.sh -L /path/to/repo -- -p git to install git and ensure that the repository will have a writable overlay.)

[zdykstra]

To get a version other than what is already recorded in the repository, it is necessary to do, e.g., zbm-builder.sh -L /path/to/repo -- -p git to install git and ensure that the repository will have a writable overlay.)

Are there any downsides to just including git by default in the build container? Anything we can do to reduce the manual steps would be good.

[ahesford]

Adding git to the standard image is probably fine.

[zdykstra]

Once this is merged, zreport() can be extended to show a few variables from /etc/zbm-release

[ahesford]

9d7eba4