Hello there,
This week I initiated a confused conversation during the techleads call about having a way to describe what the hardware pack was built from. We had a couple of false starts but I think we agreeing that there needs to be some form of manifest that describes what the hardware pack contains.
I seem to be hung up on having a way of saying "this hardware pack's kernel was built from this git tree with this config", so I wanted to explore the use cases a bit more:
- My #1 use case is, once I've installed a hardware pack, running into a problem and then being able to verify whether it contains a certain patch or was built with a certain config option. I'd like to know that because it's the first thing the KWG and LT people ask me when I go to report the bug.
- I think there's also a use case of wanting to know how to get that hwpack rebuilt with slightly updated kernel code or configs. If it's much easier to just document how to build and replace a kernel for a running image, that may cater for most of that use case, the exception being weird bugs caused by our build process and/or toolchain.
- I wonder if there's a use case for understanding and/or replacing the other contents of the hardware pack. I normally think of the hardware pack as "a built kernel and not much else" XXX.
Zach suggested SPDX (as in spdx.org) as a solution to this problem; I'm not sure I understand enough about it (Loïc's provided a sample file at http://spdx.org/wiki/sample-partial-spdx-file-geronimo) but here's my strawman proposal of what data we should give people quick access to:
- What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) - What kernel config was used to build it (A separate file in the hwpack directory?)
How does that sound? Too simplistic?