koji

#276 Method for dist tag override
Closed: Dropped by tkopecek. Opened by mikem.

Closed: Dropped
Reopen Issue

For background, see (rejected) PR#128

This feature has been asked for a few times, but it is a bit tricky for deep reasons.

The assumption in Koji has always been that the ingredients of a build are:

  • the source (scm url or srpm)
  • the contents of the build tag at a fixed event id

...and nothing else

While builds do take some options, they don't actually affect the way the build itself runs. They are not passed in to the build environment.

The dist tag is just an rpm macro defined in the build environment. This is generally done by building a special package to provide said macro (e.g. buildsys-macros) and tagging into the build tag. Changing the dist tag requires building a new package (and waiting for a repo regen).

Any satisfactory solution to this will involve adding a third input to the build process. This is a big deal and we should think carefully about how to do this right. We don't want to damage reproducibility, nor we we want to find ourselves later needing to add a fourth or fifth input.

For now, this is a placeholder for discussion. If you have ideas about this, please share them. Please do not invest significant effort into this without some open discussion and planning.

The "third input" should only be parameters for the build environment. The source should be just the source.

Why can't we hold them in Parameters for task?

Why can't we hold them in Parameters for task?

The only task parameters that are intended to directly impact the result of the build are target and source. Both of these are recorded separately as part of the build.

Also, task parameters are a mess.

What about using tag.extra as mentioned in #128, but changing some other part of koji? tag.extra doesn't have any direct impact on what repo looks alike. So, theoretically there is no need to run regen repo, if only tag.extra changed. Some more complicated semantics could be defined. When you're setting tag.extra, koji can look to tag inheritance and say if there is something new from create_event of last repo (similarly to kojira). If there is not, create_event of repo could be forwarded to create_event of tag.extra change. Otherwise it could return warning, that repository needs to be regenerated before tag.extra change will be applied.

/Catching some brainstorming without huge investigation - not sure if it really makes sense and how expensive would be such checking of changes in real world/

The modularity team was able to come up with a different approach for setting the dist tag. At the moment, it's not clear if there is urgency for this work. However, it certainly would be useful. Would like to see how this could be incorporated into a more generic method of customizing build-time parameters.

Metadata Update from @dgregor:
- Custom field Size adjusted to None

Metadata Update from @dgregor:
- Issue priority set to: Low
- Issue tagged with: groomed

Dropping as there was no action in last three years. Maybe revisit with ABI design.

Metadata Update from @tkopecek:
- Issue close_status updated to: Dropped
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/276

Please continue any further discussion there.
Metadata
None

backlog groomed wishful

None
None
Normal
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.