On Thu, 10 Sep 2020 at 13:31, Daniel P. Berrangé <berrange(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.