On Thu, Sep 10, 2020 at 1:30 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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. > This is an anti-feature and I personally will not support any effort to offer this in Fedora. That is just one step removed from not shipping it at all to people, and I don't want it to be easy for us to make that kind of decision. It *barely* makes sense in RHEL and CentOS and has massively screwed up things for CentOS SIGs (which are, with the exception of the Virt SIG, all Red Hat teams) by making it impossible for the *projects* to build their stuff on CentOS. > Modularity is being used because it is the only solution that is available > today, not because it is a good/desired solution. > Whether modularity is a good or bad solution is beside the point. The problem here is that there is effectively zero official work in Fedora by the numerous Java teams at Red Hat. With how much Red Hat is involved in the Java ecosystem, Fedora should be a freaking paradise for Java users and developers. It's almost the worst experience by a fair margin due to lack of development and improvement in the tooling and infrastructure to support the Java ecosystem. Even *Rust* is a better experience than Java, and Rust is mostly managed by Igor (with tiny bits from me, Josh, and a few others). -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
