#967 Define %{_module_context} and %{disttag}
Merged a year ago by mprahl. Opened a year ago by psabata.
psabata/fm-orchestrator disttag  into  master

@@ -251,9 +251,11 @@ 

  

          spec_content = """

  %global dist {disttag}

+ %global disttag module({module_name}:{module_stream}:{module_version}:{module_context})

  %global _module_name {module_name}

  %global _module_stream {module_stream}

  %global _module_version {module_version}

+ %global _module_context {module_context}

  

  Name:       {name}

  Version:    {version}

@@ -298,6 +300,7 @@ 

             module_name=module_build.name,

             module_stream=module_build.stream,

             module_version=module_build.version,

+            module_context=module_build.context,

             filter_conflicts=filter_conflicts)

  

          modulemd_macros = ""

@@ -310,10 +313,12 @@ 

  # General macros set by MBS

  

  %dist {disttag}

+ %disttag module({module_name}:{module_stream}:{module_version}:{module_context})

  %_module_build 1

  %_module_name {module_name}

  %_module_stream {module_stream}

  %_module_version {module_version}

+ %_module_context {module_context}

  

  # Macros set by module author:

  

@@ -321,6 +326,7 @@ 

  """.format(disttag=disttag, module_name=module_build.name,

             module_stream=module_build.stream,

             module_version=module_build.version,

+            module_context=module_build.context,

             modulemd_macros=modulemd_macros)

  

          td = tempfile.mkdtemp(prefix="module_build_service-build-macros")

No reason to hide module context from the consumers, plus it's useful to
keep it in the DISTTAG tag (not to be confused with the %{dist} tag) for
tracking.

The %{disttag} feature will do nothing until RPM supports it. This is
planned in 4.14.2.

See https://bugzilla.redhat.com/show_bug.cgi?id=1596192.

Signed-off-by: Petr Šabata contyk@redhat.com

What's the point of defining "disttag"

We would like to reliably identify modular RPM packages even when the repodata is missing.

Originally we wanted to add new provides but that turned out to be impossible -- autoprovides scripts don't have access to our macros and wouldn't work for empty packages. There doesn't appear to be any magic macro we could extend to add them either.

After discussing this with RPM devs, we decided to use the virtually unknown and unused DISTTAG RPM header to store this label. Keeping the NSVC in these is not necessary but it might be useful for tracking in the future.

But what if RPM is used by multiple modules? Which one would you put in disttag?

Well, whichever one it was built in @ignatenkobrain (according to the implementation here).

Yes, just the one for which it was originally built. This doesn't serve any technical purpose anyway.

From discussion elsewhere, it seems like @psabata wants to treat the disttag header as a boolean. If it is set, then treat the rpm as a modular (so-called "canine") rpm.

I'm good with this. :thumbsup: from me.

rebased onto 3238809

a year ago

Commit e45863e fixes this pull-request

Pull-Request has been merged by mprahl

a year ago

Pull-Request has been merged by mprahl

a year ago
Metadata