On Thu, 10 Sep 2020 at 13:31, Daniel P. Berrangé <berra...@redhat.com> wrote:
> 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. > > The problem is that you may need differing packages for your 'build-root'. This means that someone has to determine if your buildroot only has foobar-1.2-3 or foobar-2.3-4 which are neither wanted to be in the buildroot but unison-2.1 needs one and unison-2.2 needs the other. [Or some toolkit where to get to the next version you need to compile a version before the one you have with different yacc/etc and then need the next version to finish the build.] The more fundamental problem is that everyone assumes that if it lives in the buildroot only.. it magically doesn't have any bugs which can cause problems with a package being compiled by it. Instead it is now a package which no one can easily inspect to see that XYZ app is dumping core because your buildroot only yacc is a recycled road apple. > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
