The prototype flatpak-runtime module that I’ve been working on is built upon
the (F26) base-runtime and shared-userspace modules, and I’ve hit some
conceptual questions about the nature of the “modulemd” requires relationship.
* Is a module tied to the exact version of the modules it requires that it was
built against, or can it be used with an updated version of that module within
the same stream without a rebuild? (For a module like shared-userspace or
flatpak-runtime that buildrequires bootstrap rather than base-runtime, this is
a slightly funny question since it wasn’t actually built against base-runtime,
but ignoring this current oddity.)
* What happens if there are packages in a module that you require that are not
in the api of that module, but also not filtered out. If you need them, should
you rebuild them in your module? Is this a packaging error in the module?
* How do you properly handle the case where a module filters out some
subpackages of a package. For example, base-runtime builds
gobject-introspection but filters out gobject-introspection-devel because it
brings in a lot of python2 dependencies.
These questions interact in some interesting ways. Imagine:
1. My module needs gobject-introspection-devel as a build requirement, so
includes gobject-introspection in its list of packages. If the NVR is newer
than the NVR in base-runtime, but they are binary compatible, then the
gobject-introspection I build will cleanly replace the one from base-runtime.
2. shared-runtime is then updated and rebuilt to have a newer version of
gobject-introspection than my module. With both modules available in a DNF
environment, then, as far as I know:
dnf-install gobject-introspection-devel will install the version of
gobject-introspection from my module (since gobject-introspection-devel
requires the exact NVR of gobject-introspection)
dnf-install gobject-introspection will install the version of
gobject-introspection from base-runtime since it is newer.
My general takeaway is that there needs to be pretty strict rules about how you
create a module that is meant to be used as a dependency of other modules - or
in fact, any module that is meant to be installed in the same filesystem as
other modules. Can filtering out subpackages to avoid runtime dependencies work
in this case?
Owen
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
