Reply to comment

Re: Module metadata proposal

By Petr Sabata at 04/21/2016 - 15:32

On Fri, Apr 15, 2016 at 05:19:04PM +0100, Stephen C. Tweedie wrote:
Should be simple. We just bump the version number if it's a
breaking change. I also maintain a small library that should
provide an abstract API for handling this.

A buildrequires field was present in an earlier draft but I
removed it as it wasn't (and still isn't) entirely clear what
it actually means to build a module. I expect to put it back
once this is more clear.

You can define versioned module runtime dependencies in the
requires field.

Currently -devel (and other) subpackages are included if the
fulltree option is set to true. This is the default.

This is an interesting idea. Noted.

At the moment we list the "main" components of the module.
Other packages, such as the related subpackages, source RPMS
or debuginfos are automagically included if the fulltree option
is enabled (again, defaults to true).

Dependencies of the listed components that aren't provided by
any of the required modules are also included in the module if
the dependencies option is enabled (also defaults to true).

I would say the listed components could be considered the
"official API" and the bundled (an ugly word, I know)
dependencies would be the internal implementation detail.

You could also place comments in the (source control tracked)
YAML file for extra information. Of course these wouldn't
be normally visible to any processing tools but I don't think
that's important. Correct me if I'm wrong.

These are available via the fulltree feature, without the need
of listing them explicitly.

The same as above. We might split fulltree into two or more
options later, if required.

If it's a bundled dependency, an implementation detail, it would
be remove automatically the next time you build the module --
in case none of your main components needs it anymore.

Again, extra info could be added as comments.

Or do you think it'd be useful to have these as separate fields?