On Thu, Sep 10, 2020 at 06:30:05PM +0100, Daniel P. Berrangé 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.
Modularity is being used because it is the only solution that is available
today, not because it is a good/desired solution.
+1
The ability to hide/not-distribute build-only packages is frequently
cited as a benefit of modularity, but it breaks down when you have
multiple packages across modules share build-only packages. If
moduleA and moduleB both have a build-only package named BuildTool
then those module developers should work together to either jointly
maintain BuildTool -or- duplicate BuildTool across both modules.
Since the advantage stated is being to hide build-only packages, this
makes it impossible to discover what build-only packages might exist
that you could use in your module. With this example, modularity
leads to the bundling problem we've [Fedora] been very public about
disliking in the past.
The buildroot tries to solve that, but we already had a solution for
that and it was the repo. Labeling packages as build-only or grouping
them as build tools only or otherwise marking them as packages that
exist to build other packages could be done in numerous ways that
still makes those tools discoverable to other package maintainers and
developers.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
