On Thu, Sep 10, 2020 at 7:31 PM 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.
Yes. This can also be achieved with on-demand side tags that are already implemented: "build-only" packages are built in a sidetag and untagged before sidetag is merged. They never appear in release tags and they are not shipped to users. Builds can be reproduced locally in mock with configs generated by "koji mock-config" command. > Modularity is being used because it is the only solution that is available > today, not because it is a good/desired solution. Right. Modularity is definitely not the best solution, and IMHO it definitely has worse user experience compared to ursine packages. Modularity is used because it was the only solution available at the moment the decision (to modularize Maven and Ant) was made. Since then an alternative solution was developed, but we haven't decided to switch back to ursine packages yet, although we are considering that. > > 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 _______________________________________________ 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
