On Thu, Apr 21, 2016 at 04:37:35PM -0400, Neal Gompa wrote:
On Thu, Apr 21, 2016 at 4:32 PM, Petr Šabata contyk@redhat.com wrote:
On Fri, Apr 15, 2016 at 05:19:04PM +0100, Stephen C. Tweedie wrote:
Hi,
On Thu, 2016-04-14 at 18:35 +0200, Petr Šabata wrote:
the first draft of the module metadata format is now available
for you to comment on. We've decided to go with YAML so it should be fairly readable. You can view the latest version here:
https://pagure.io/fm-metadata/blob/master/f/metadata.yaml
What is is: The file defines basic properties of the module such as its name, version, description, licenses, references to upstream documentation or its content. Currently only RPM content is supported but this can be easily extended in the future. The metadata file is meant as both input and output of the module build process (don't confuse it with package build process), with various tools adding various new data to it, such as vendor and buildsystem identifiers, timestamp of the build, autogenerated lists of licenses or whatever you can think of (well, maybe not whatever but close). The output is then placed in the generated repository, container image or any other module deliverable and can be processed by tools and services consuming and delivering modules.
What is isn't: It's not a SPEC file. It doesn't say how to build individual packages. And it's not a simple comps group either. It can and does provide lots more additional data.
It's not perfect and it's constantly evolving. Please, do comment, ask questions and suggest improvements.
What makes this different from how comps metadata works? I look at this, and I wonder why we don't just evolve the comps format and perhaps make it easier to construct comps data. I honestly don't see a reason to add yet another metadata format when it doesn't seem to make sense. I understand why you use YAML for input, as that makes it easier for people to structure the information, but perhaps dynamically translating that into comps information would allow us to reuse the infrastructure we already have.
Metadata proliferation is evil, please don't contribute to it unnecessarily.
Everyone involved in the initial discussion was against XML and YAML won over JSON for its readability and features (such as, well, comments).
This is a working defintion that will definitely change over time. If it proves useful, we might as well extend the comps format and the tooling could translate into it on the fly. This isn't definitive.
P
-- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org