On 2017-07-03, Owen Taylor <otaylor@xxxxxxxxxx> wrote: > * 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? It's bound to the stream. Modules are expected to preserve ABI inside a stream. You don't need to rebuild your module. > * 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. This is not-yet-answered question. In ideal world these packgages should have module-specific name and should install all its files into module-specific path (module+stream-specific to be precise). But the reality is nobody does that. The partial answer was "nobody cares because we have containers". But that does not solve the case when you need more modules into one file system, as you correctly pointed out. I forsee modifying spec files in software collection (SCL) manner to achieve this but SCL is unwelcome technology in Fedora and withot module-specific branches in dist-git or change in Fedora posture it cannot be implemented. > If you need them, should you rebuild them in your module? Is this > a packaging error in the module? > Yes. Basicly modules should not use anything that is not listed in other's module API package set. If they need it, they should rebuild it for themselves. But again, it creates file conflicts and due to hash-based disttag also incomparable package NEVRA. > * 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. > Rebuild the package under different name into different path and modify your code to use it from the different path. But again, it's hard without changing the spec files. > 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? > I totally agree. -- Petr PS: I'm not a modularity author, the modularity team could have better answers. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
