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-leave@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