On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote: > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote: > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote: > > > > > 4. The benefit we want to preserve from modules is to maintain packages > > > with varying expectation of quality, specifically separating the > > > build-time-only vs runtime dependencies. e.g. in that case that a web > > > server like Eclipse Jetty is required as a dep for testing another > > > component during the build, we want to be able to use and build that > > > component, without being indefinitely on the hook for security errata. > > > (The build dependency tree is particularly complex for Maven and > > > involves many examples of packages with frequent and high severity > > > vulnerabilies) > > > > What are you doing different in terms of supporting deps in the module > > that reduces the security errata burden, compared to non-modular builds ? > > > > It feels like if we have some policy that is creating unsustainable > > maint burden wrt non-modular packaging, we should re-examine this > > policy rather than trying to workaround it by going modular, which > > creates a different kind of maint burden. > > > In non-modular Fedora all packages that we have in Fedora build system (Koji) > are tagged into Fedora repositories and made available to all users on their > computers for any purpose. That implies that all packages in Fedora build system > must be fully supported including addressing all security issues. > > In modular Fedora that's (effectively) not true. Packages that only exist > for the sake of building other packages (i.e. build-only dependencies) can be > retained in the Fedora build system and never left it. That means those > packages are never made available to Fedora users and thus a service level for > them is significantly lower. E.g. no security fixes, not bug fixes, no > integration, not tests, no API/ABI stability. The only requirement is that > they can be built and used for building other packages. So conceptually, one way we can solve this problem by implementing a way to mark certain non-modular RPMs as "build root only" packages and thus composing them into a separate "build root" yum repo, that is not enabled by default except in the build system. Modularity is being used because it is the only solution that is available today, not because it is a good/desired solution. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
