Last week, I put out a blog post and fedora-devel thread describing the problems that we wanted to solve with Modularity. That thread was not ultimately as successful as I had hoped. My intention was to provide some scope to the problem, because it seemed that a lot of alternatives being floated were not seeing some of the more subtle cases that we were trying to address. However, the biggest problem is that nearly every email to the list has been started with a "Begging the Question" Fallacy. People have started from the premise that "Modularity is Bad" and all of the rest of the conversation has continued from there. I'd like to provide an opportunity for us as a community to *constructively* state our grievances with Modularity. The fundamental root cause of some of the miscommunication is, I believe, that Modularity has problems and that people have assumed that they are fundamental and unfixable. I'd like to gather a constructive list of the actual use-cases that you feel Modularity is causing problems for, with the following stipulations: Any *subjective* problems will be ignored. "I think writing YAML is harder than writing a spec file" is an example of a subjective opinion. Similarly, "change inevitably results in some learning curve" is a basic maxim of innovation and is not in and of itself an argument not to change. "Modularity requires me to write both a spec file and a YAML file, thereby increasing the total work" is an *objective* observation (and a valid one; I'm going to include it below in my own starter list). If you aren't sure if it's objective, a useful question is "is it quantitatively measurable?" (AKA "Can I assign a number to it and see that number increase or decrease when changing something about the implementation?") So, in the interest of highlighting some specific cases where the current, deployed[1] implementation (in no particular order): 1. Once enabled, a module stream is never changed on behalf of the user. While this adds some strong guarantees to those who want to run applications built from those streams, the presence of default streams changes the expected upgrade behavior for users. Traditionally, at upgrade a user would get the new release's most-updated version of all packages currently on their system. With Modularity, if one of their packages comes from a default stream and that stream is not the default for the next release, they will stay on the current stream (or be blocked from upgrading, if the current stream is unavailable on the next release). [2] 2. Packages moved out of traditional Fedora and into a default module stream are not available to the non-modular buildroot. [3] 3. Insufficient guidelines and rules have resulted in some modules being shipped in a state that makes it difficult or impossible to build other software for the distribution. In particular, the 'ant' and 'maven' modules have default streams that own the namespace of several of their dependencies that have been configured for private use rather than public to the rest of the distrtibution. [4] 4. Documentation of how to create a module stream is comprehensive but daunting. There is a lot of available information, but what is really lacking is a basic walkthrough for converting a single package to a module stream. 5. There is no specification defined for dropping a default or enabled module stream and returning to non-modular packages. 6. We don't provide a direct solution for parallel-installability. This is an intentional design decision, but it *is* arguably a regression from SCL functionality, so I'll include it here. 7. The implementation in DNF occurs in libdnf rather than at the libsolv layer, which makes it difficult to reimplement for other packaging or build tools (such as GNOME Software and OBS, resp.) 8. The YAML format for modulemd is complex and can be difficult to get started with. [5] [6] 9. We don't have a good document on how to MBS generates modules and their repositories. This makes it hard for other build-systems to replicate the behavior. [7] 10. The MBS has performance issues which make official builds take a long time. [8] 11. "Module Stream API" when used in a default stream causes package incompatibilities and unsupportable configurations. [4] 12. Packaging a module requires writing both a spec file and a modulemd YAML file, which increases the total amount of work I need to do. [5] I'm sure there are other pain points and I encourage you to share them. Please adhere to the guidelines about objectively measurable issues, though. --- [1] I'll highlight with a [N] any of the cases I list that have a non-deployed fix, mitigation or are under design. [2] This is an identified user-experience issue and is under active design discussion on other threads. Please do not rehash that here. Some of the options being considered are: - Record whether the user "locked" themselves on a stream or had it enabled because it happened to be the default stream and they installed a package from it. - Add new metadata for the streams: "Upgrades:" and "Obsoletes:". - Drop support for default streams in Fedora 32, moving all content in default streams back into the non-modular space. [3] We have an initiative (not a service) called "Ursa Prime" which is essentially a pungi config that imports the modular repo into the buildroot and relies on mock using DNF correctly to pull in the appropriate packages from default streams (meaning it will work on local mock builds as well as Koji builds so long as we modify the mock repo config to include the modular repos). This is in contrast to the original "Ursa Major" project that would have been a separate service in Fedora Infrastructure dedicated to tagging the artifacts from a specific set of module streams into the buildroot tags. "Ursa Prime" is ready and could be deployed at any moment, pending FESCo approval of https://pagure.io/fesco/issue/2255 [4] The Modularity WG and FESCo agreed a few weeks ago that if any module stream is shipped as a default, all of its artifacts must conform to the same behavior as expected of a package shipped in the traditional manner. This also means that as part of the Fedora 32 process, we would need to go through any default streams and ensure that they are in compliance or remove their default stream until they are. [5] We have a tool called `fedmod` that has a command `rpm2module` that does a lot of the bootstrapping work but that no one seems to know about. [6] I've proposed a backwards-compatible 'modulemd-packager' YAML format that trims out the extra content that only the build-system uses and that the packager could ignore. See https://github.com/fedora-modularity/libmodulemd/issues/364 [7] I wrote a blog post on how to generate module repositories without using MBS as a reference implementation: https://sgallagh.wordpress.com/2019/08/14/sausage-factory-modules-fake-it-till-you-make-it/ [8] MBS is aware of this and is re-architecting its worker design to improve it. https://pagure.io/fm-orchestrator/issue/1311 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
