Re: Modularity: The Official Complaint Thread

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Nov 12, 2019 at 4:17 PM Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> wrote:
On Tuesday, 12 November 2019 at 22:07, Stephen Gallagher wrote:
> On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
> <dominik@xxxxxxxxxxxxxx> wrote:
> >
> > On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
> > [...]
> > > I agree with Aleksandra here. And we *did* establish that our policy
> > > going forward is that we will forbid any default stream from providing
> > > non-API content. (Filtered out packages are orthogonal to this.)
> >
> > What does that even mean?
> >
>
> Modular builds have metadata that can indicate to consumers which
> subpackages in this module should be considered "API". If a module
> produces a package artifact and does not list it thusly, it is meant
> to be treated as an internal implementation detail of the module (and
> that the maintainer is not committing to maintaining that particular
> package for any purpose other than supporting the API content of this
> module).
>
> We also have "filters" which are intended for allowing module
> packagers to build and use build-time-only packages. They are built
> and added to the module buildroot as part of the build process, but
> they are filtered out so they don't end up in the final composed
> repository. (This is useful if, for example, your package used a small
> subset of some other package only at build-time and you don't want to
> have to maintain that package for everyone in the distro just to build
> yours).

OK. Let's say one of those is a static library that doesn't get exposed
in the final composed repository. Suppose there's a security bug in that
exact version but that bug doesn't occur in the traditionally-maintained
package in Fedora (perhaps because the vulnerable version was skipped).
How do you detect that and know which packages (modules?) need to be
rebuilt?

A few points:

* Static libraries are forbidden by Fedora policy already.

* If you are bundling into one of the produced RPMs, the same “Provides: bundled(foo)” rule applies as it would for a non-modular RPM.

* The build artifacts are still present in Koji, they just don’t end up in the final composed repos. So we can always query Koji for the version corresponding to a module build.

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux