fesco

#1705 MBS and the module-build-macros package.
Closed: Fixed Opened by ralph.

Closed: Fixed
Reopen Issue

A question has come up about the Module Build Service[1] that needs FESCO's attention.

As one of the first steps in building a module, the MBS synthesizes a spec file
for a "module-build-macros" package. This specfile is submitted as a SRPM
build. An example can be found here[2].

Release Engineering has raised concern that we have a policy requiring that all
sources be built from dist-git[3]. The spec file here though is synthesized on
the fly by the MBS and is never committed to any dist-git repo.

I'm asking for FESCo to weigh in on this. Does the module-build-macros package
need to be committed to dist-git? Or is this scenario outside the bounds of the
problem that the policy was originally intended to address?

As to the first option, we could create a dist-git repo for the
module-build-macros package. We could modify the MBS to commit to it for every
module build. The commits would be almost identical, with the name, version,
stream and auto-generated dist tag macros being the only differences. MBS
could then be re-tooled to submit builds from this repo. We would then have to
root the old auto-generated srpm macros out of the koji history. Since things
have been built against them, we would have to start over, re-bootstrap
everything, and rebuild everything. This is not possible in the F26 timeframe.

The second option makes more sense to me:

  • The policy in question is in part about auditability. We need to be able to
    discover what sources went into everything we built. The way things
    currently stand with the MBS, we can find the srpm from the koji task,
    extract the spec file, and read it.

  • The policy is also about reproducibility. If we built content willy-nilly
    from the Internet and that content disappeared some day, we wouldn't be able
    to rebuild. The module-build-macros though are deterministically
    generated. If we need to rebuild modules, we can ask the MBS to do so and it
    will produce the same specfile it did the last time (reproducibility is a
    core design principle of the MBS).

Even though it is submitted to koji as a "source" rpm, the
module-build-macros spec file is not really source. It is not meant to be
edited by humans. It is programatically generated[4]. Keeping it in dist-git
doesn't make sense.

Sorry that this has come up on such late notice for FESCo. Release Engineering
raised the concern on May 11 and recommended that we take it to FESCo.

[1] https://fedoraproject.org//wiki/Changes/ModuleBuildService
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=889643
[3] https://fedoraproject.org/wiki/Packaging:Guidelines#Build_time_network_access
[4] The mock configs used by koji are also technically necessary to reproduce
builds, but they are auto-generated and not stored in git.

The module files from which the generated spec files are in dist-git, right?

In any case, I'm not sure the policy as written really reads on this. Isn't it intended to prevent dependencies on external resources? In this case, the MBS is something internal. I think this could be patched by simply changing:

In no cases should source code be downloaded from any external sources, only from the lookaside cache and/or the Fedora git repository.

to

In no cases should source code be downloaded from any external sources, only from the lookaside cache, Fedora git repository, or Fedora's Module Build Service.

It could even be made more general, but I'm fine with the conservative approach of approving the MBS individually.

In general, I'm in favor of not letting policy get in the way of delivering important work. That said, I feel it necessary to raise a couple points so that we can discuss them.

The policy in question is in part about auditability. We need to be able to
discover what sources went into everything we built. The way things
currently stand with the MBS, we can find the srpm from the koji task,
extract the spec file, and read it.

There are actually limits to this; today, Koji will automatically reap task history to save space after some number of weeks for anything that is not tagged for a release, update or pending update. So we may need to modify the way we retain this data (which may have many different solutions, but may also necessitate an investment in storage).

The policy is also about reproducibility. If we built content willy-nilly
from the Internet and that content disappeared some day, we wouldn't be able
to rebuild. The module-build-macros though are deterministically
generated. If we need to rebuild modules, we can ask the MBS to do so and it
will produce the same specfile it did the last time (reproducibility is a
core design principle of the MBS).

Can we do that perfectly? As in we have a guarantee that we'll end up with an identical SRPM and RPM (complete with cryptographic hashes)? If that's the case, this probably covers the auditability case above as long as we just retain a list of those hashes somewhere.

Even though it is submitted to koji as a "source" rpm, the
module-build-macros spec file is not really source. It is not meant to be
edited by humans. It is programatically generated[4]. Keeping it in dist-git
doesn't make sense.

Right, so the idea is that the module-build-macros RPM is meant to be generated as an internal implementation detail of the build-system and not as a "real" RPM. Correct me if I'm wrong, @ralph but the RPMs here should only ever turn up in the buildroot and not be part of the produced module repository.

Sorry that this has come up on such late notice for FESCo. Release Engineering
raised the concern on May 11 and recommended that we take it to FESCo.
[1] https://fedoraproject.org//wiki/Changes/ModuleBuildService
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=889643
[3] https://fedoraproject.org/wiki/Packaging:Guidelines#Build_time_network_access
[4] The mock configs used by koji are also technically necessary to reproduce
builds, but they are auto-generated and not stored in git.

Metadata Update from @maxamillion:
- Issue tagged with: meeting

Given the explanation, I'm fine with how the MBS works today.

Metadata Update from @jwboyer:
- Issue untagged with: meeting

Metadata Update from @jwboyer:
- Issue tagged with: meeting

The module files from which the generated spec files are in dist-git, right?

Correct. See an example: http://pkgs.fedoraproject.org/cgit/modules/base-runtime.git

[on reproducibility] Can we do that perfectly? As in we have a guarantee that we'll end up with an identical SRPM and RPM (complete with cryptographic hashes)? If that's the case, this probably covers the auditability case above as long as we just retain a list of those hashes somewhere.

For the SRPM, it should be bit-wise reproducible. The RPM will run up against the bit-wise reproducibility problem that we have for all binary RPMs.

...the RPMs here should only ever turn up in the buildroot and not be part of the produced module repository.

That is correct.
  • ACCEPTED: FESCo is okay with the modules built to date being
    shipped as they are (5:+1 0:0 0:-1) (dgilmore, 16:37:52)

We will work on a long term plan on how things are to be supported

Metadata Update from @ausil:
- Issue untagged with: meeting

Metadata Update from @sgallagh:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.