Starting with a summary: Let's 1) use something like dependency-report scripts [1] to get coordinated, and 2) make the initial builds against bootstrap so we get a working thing fast and can iterate.
I've realized that developing the initial set of modules for F27 could be a bit tricky in the beginning as some things might require many basic dependencies on top of Platform to run and build. These dependencies, like autotools or dynamic languages for example, need to get modularized first. In F26 Boltron we had a 'shared-userspace' and 'shared-build-dependencies' modules that kind of randomly included many of the shared dependencies of other modules. I don't think that's necessarily terrible (although I'm sure contyk would argue it is!), but it's not ideal. We should make modules that represent a thing, like autotools, python2, python3, ruby, gtk2, gtk3, git, etc. But making all of these modules on a greenfield without a solid base could be tricky. How do we help people to know what they should include, and what's going to be somewhere else? For this, I have written a set of scripts, and already named them badly 'dependency-report' [1]. We have tested it with FreeIPA maintainers to generate a dependency report [2] for them, and we have already identified many modules that FreeIPA need as dependencies. I think we could use this to help us with the initial design. This brings me to my second thought... to build what we want, we need to modularize a lot of other stuff. And when we are ready with the initial design - that means we have identified all the modules we want to have and all their dependencies, we need to build them. But, for example, a pretty commonly needed thing like autotools [3] has pretty crazy build dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2, python3, etc. And many of these need autotools, of course. We need to do bootstraping. So instead of trying to make everything perfect from the begining, we could build everything we need against the Bootstrap module - a module that is used as a buildroot for Host and Platform and contains mostly everything we need. To compare, there is a report without using bootstrap [5] and with using bootstrap [6]. This way we'll have a pretty decent set of module very soon. The next step would be lookin at the build dependencies of these initial modules, building them against bootstrap, and rebuilding the initial modules against these new ones. And then do it for the new ones as well, until we have everything in place. Also, with this top-down approach, we'll be flexible with the frequent changes of the Platform module as it's getting stabilized which also makes the design of the low-level modules nearly impossible right now. With this approach, we: 1) get coordinated and make modules without conflicts 2) have a working thing very soon 3) can iterate on expanding the base set over time If you'd like to participate, please feel free to propose your module on the F27 content plan [7], I'll make you a repository under the modularity-modules space [8] which serves as an input to the scripts, and include your module in there. Cheers! Adam [1] https://github.com/fedora-modularity/dependency-report [2] https://github.com/fedora-modularity/dependency-report/tree/master/modules/freeipa [3] https://github.com/fedora-modularity/dependency-report/tree/original-plan/modules/autotools [4] https://github.com/fedora-modularity/dependency-report/blob/original-plan/modules/autotools/all/buildtime-binary-packages-short.txt [5] https://github.com/fedora-modularity/dependency-report/tree/original-plan/global_reports [6] https://github.com/fedora-modularity/dependency-report/tree/bootstrap/global_reports [7] https://github.com/fedora-modularity/f27-content-tracking [8] https://github.com/modularity-modules -- Adam Šamalík --------------------------- Software Engineer Red Hat
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
