I'm concerned about this, it would be the first time a command-line parameter would affect the output of a rpmbuild.
Right now the disttag is controlled by rpms installed into the buildroot. Is there a reason this wouldn't work for modules? I expect each module would have its own build tag/target, and could have its own version of redhat-rpm-config which sets the disttag.
If we want to make the disttag more dynamic (not dependent on buildroot contents) it should be a config parameter on the -build tag (an entry in tag.extra), not a command-line parameter.

Hi Mike,
I'm not really sure if setting the disttag with a commandline is the right thing to do either. I've tried to gather some input on this at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FTGVRRVL4KHWRDMGIOYS3E4CH3XMIY6K/ and we've even tried to overwrite the dist tag by adding a special package with this macro, but that just isn't dynamic enough if we need to several module-builds.
The good thing is that no user should ever need and be allowed to do this, only the Orchestrator
( http://fedoraproject.org/wiki/Modularity/Architecture/Infra#Orchestrator_as_the_owner_of_module-build ) would need this.
I can certainly modify this patch to use tag.extra if you think that would be a better appoach. Or if any other solution comes up, I'd be happy to provide a patch.

Can you give an example of how the disttag would be used in module builds? Just trying to understand the variables.
Personally, I would support a tag.extra-based solution above a command-line option, but we should probably discuss it with @mikem as well.

There are some builds on http://koji.stg.fedoraproject.org/koji/ that show how the disttag is used for module-builds. An example is bash: http://koji.stg.fedoraproject.org/koji/buildinfo?buildID=760013

Using tag.extra is appealing, however that is data is versioned and the builder queries at the event corresponding to the repo it is using. So, one would still have to wait for an updated repo (and aiui part of the reason of this is to avoid waiting on a repo regen).

At the moment, our model is for rpm builds is:
build inputs = sources + build tag (at fixed event)

At the moment, the dist tag is part of the build tag (via a build that provides the macro). As explained in the request, using the sources instead not viable because folks want to take the same source and build for multiple targets.

What I'm a little unclear about is why we want the dist tag to vary so quickly for builds in the same build tag.

/me looks at the example

http://koji.stg.fedoraproject.org/koji/buildinfo?buildID=760013

NVR: bash-4.3.33-2.testmodule_4.3.43_6

So the dist tag here is: .testmodule_4.3.43_6 ??

How is this not a gross abuse of dist tags?

(and aiui part of the reason of this is to avoid waiting on a repo regen).

Right, that's my understanding too.

So, one would still have to wait for an updated repo.

We currently have to:

• Set up the tags and target.
• Build our special macros package.
• Wait for the repo to regen.

I think the aim of this patch is to get rid of the time spent in step 2. We were hoping to get rid of steps 2 and 3 both, but c'est la vie.

It seems to me that in order for this to be merged, it would first need to be reworked to leverage tag.extra, no?

Closing this for now, until it can be reworked