On Thu, Sep 10, 2020 at 9:59 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote: > > maintain the non-modular packages. We are not going to promise to > > commit time and resources to maintain the non-modular packages. > > Joe, here's a part I hope you can help me understand better. Modularity > isn't an entirely new packaging technology. It's simply a layer on top of > RPM. Modules are made out of RPMs, and by design, their specfiles are > exactly the same as RPMs which happen to be grouped into modules. Modularity provides not only a different way of grouping or delivering RPM packages, but most importantly, a different way of building RPM packages. You get a side tag in Koji where you can have private build-only dependencies that are discarded (filtered) once they are no longer needed, after module build is done. For build-only packages most of security vulnerabilities are not exploitable easily, or at all, therefore are low-severity, which greatly limits maintenance work required to address them. For example, if upstream tests are ran on an obsolete, 12-years old version of Tomcat, I don't need to skip tests, but I can package old Tomcat and run the tests. I don't need to update that Tomcat or fix security issues as they are not exploitable in buildroot - Tomcat runs in embedded mode, does not listen on the network etc. Not something that I could with ursine Tomcat packages - it would get delivered to users, and we have no control how they use it - we would need to fix all important user-reported bugs and CVEs as they are potentially exploitable. Modularity also introduced the concept of API packages - non-API packages can have limited usability, with some non-important features removed. For example if all I need is a small part of Tomcat, I can reduce tomcat package to build just the tiny parts that I need, which don't have any dependencies. Again, not something I could do with ursine Tomcat package. Another, more concrete example: core Ant doesn't have any dependencies beyond JDK. It is easy to build and maintain, yet very functional. On the other hand, full Ant with all the optional tasks depends on more than 200 Java packages. For the purpose of building all packages that I am interested in, core Ant with JUnit tasks (total of 3 packages) is sufficient. Functionalities of Ant like sending emails or image processing are obviously not needed in this case. If building other packages is the only use of Ant then it can be maintained much more easily (3 instead of ~250 packages). But when Ant is ursine package in Fedora then it should be the full Ant - we can't claim to deliver Ant to users while it is just part of it. Eclipse in Fedora requires full Ant too. > I understand that it's nice to have exactly one workflow, but it doesn't > seem like it's actually all that much extra effort on top of what you > already have to do to maintain the module to make a non-modular build. Is > this something where triggering the non-modular builds in the same way you > build the module would make a difference? It's not about the workflow, it is about reducing package maintenance work that is required. Modularity allows us to greatly reduce the number of packages by patching-out non-API packages to remove unneeded features and it allows us to spend less time on fixing bugs in packages that are used merely as build dependencies and which we don't intend to be used by end users. > > Or is there something else that I'm not seeing? > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > 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
