I wonder who is doing to clean up all the mess in dist-git we have due to modularity. specifically, I wonder about all these branches: https://src.fedoraproject.org/modules/nodejs/branches?branchname=master https://src.fedoraproject.org/rpms/nodejs/branches?branchname=master What is their state? Vít Dne 05. 11. 19 v 21:17 Stephen Gallagher napsal(a): > 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 _______________________________________________ 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
