On Thu 01 Jun 2017 11:45:07 AM CEST Tomas Hoger wrote:
On Mon, 29 May 2017 11:42:49 -0000 Stanislav Ochotnicky wrote:
> > On Fri, May 26, 2017 at 10:25 AM, Stanislav Ochotnicky
> > <sochotnicky(a)redhat.com> wrote:
> >
> > Is it possible to fix a module in isolation? Or would the fix have to
> > be applied to its constituent RPMs?
>
> Right now the fix would have to first go into the rpms which would be
> normally shipped through Bodhi. Idea long term seems to be that
> Fedora would be completely modular so there wouldn't be traditional
> rpms shipped if they are not part of a module.
I still agree with Florian here - it's reasonable to track affected
components at their source (srpm / dist-git branch). Automation needs
to take care of knowing which modules bundle which components, and
hence figuring out which modules need rebuild if some change is applied
to the source.
Sounds good. So basically the idea is - each component that goes into
modules has to have a component in bugzilla. Even if component is in
multiple modules it will only have single component in bugzilla.
I do wonder how this will work with arbitrary branches work - where
dist-git would likely have separate branches for openssl-1.0 and
openssl-1.1 in your example.
Note that I do not think this problem is specific to security fixes
-
it's the same problem for bug fixes. I also had an impression the
automation part was on the list of things that are required for
modularity to happen.
Sure the rebuilding part itself will be handled by freshmaker project -
it's being worked on right now. But we don't have a good grasp of
how exactly CVE tracking will differ from current world (if it will at all).
> Generally - don't expect there will be a "single rpm
with fix for
> CVE-1234 in F27" but rather "several rpms - each with different NVR
> based on which module they were part of for given CVE fix. They
> could/would all still likely be built from the same dist-git branch -
> but due to module macros end with with different release tags.
As noted above, that's something automation needs to keep track of.
Asking folks to handle that manually is unreasonable.
I am not asking that anyone does this manually. I am asking what will
break when the mapping is no longer: one component/bug -> one shipped
build but it will be (based on what you said above around having single
component in bz): one component/bug-> multiple modules with multiple
component NVRs for the same source rpm
I bet there are custom things you have that will be affected. We want to
help you understanding/preparing for the changes.
What will require a change is tracking of multiple versions of a
component in one Fedora version. E.g. assume that F2x will have 2
versions of openssl - openssl-1.0.2 and openssl-1.1.0. Do we already
have a concrete information on how that's going to be handled in
various systems (BZ, dist-git, ...)?
Partially - basically if you can review this change proposal and provide
feedback about what we forgot about that might help:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer, PnT DevOps - Brno
PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241
Red Hat Inc.
http://www.redhat.com