Reply to comment

Re: Module metadata proposal

By Stephen C. Tweedie at 04/15/2016 - 12:19


How easy is it to modify and change field definitions around?  I see
you've got a version identified for the format already --- good, that's
definitely something we want here.

One thing I think we need is a bit more detail in the module
dependencies.  We don't need them all for the initial task of building
a module and testing its repoclosure; but I think we may well have a
need for (for example)

* Package build deps: what other modules you need to compile packages
in this module.  (This basically defines the build root for the
module, and we want to be able to make sure we're using a consistent
build root with consistent compiler versions etc. for all the
packages in a module.)

* Runtime deps: what other modules need to be enabled by the user at
runtime to use this module.  Eg. library dependencies, CLI tool

* -Devel deps: what other modules need to be enabled by the user to
build applications against this module.

We could also expand on the module ID a bit.  Many packaging systems
use a hierarchical naming scheme --- eg. instead of name: foo, name
might be "".  A maintainer name and reference download
URL/homepage could also be useful here.

But the main place I'd like to see expanded is the package list itself.
In addition to the list of packages included, I think we need:

What is the function of the package?  It may be:

* A runtime component which is part of the official API of the module.
We can do things like verify ABI compatibility on these components
on updates if we want.

* A runtime component which is an internal implementation-detail only
(similar to the distinction between unstable, internal and stable,
external symbols in a library.)  A user should know not to rely on
these components remaining the same on module updates.

We should also record which externally-usable package needs this
internal dependency in this case.

* A -devel package: never needed at runtime; only used if a developer
is building an application against the module.

* Debuginfo.  We could choose to keep debuginfo in the module itself,
marked this way; or we could keep separate debuginfo lookasides or
separate debuginfo modules.  Not sure which way we'll eventually go,
but it would be useful to at least be able to mark packages which
are included only for runtime debugging.

For long-term distro maintenance, it will be *hugely* helpful to be
able to look at content and say "why do we have this package?  Does
anyone actually need it, or is it only there to satisfy some dependency
for an application that was added years ago and might not even need it
any longer?"

Making the distinction between external and internal functionality, and
recording explicitly what needs the internal pieces, will really help
that sort of long-term maintenance, making it much easier to see when
dependencies are no longer needed.