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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
