#83 Add %new_package
Merged 2 years ago by tibbs. Opened 2 years ago by nim.

file modified
+116 -19
@@ -1,7 +1,46 @@ 

  -- Convenience Lua functions that can be used within rpm macros

  

- -- Set a spec variable

- -- Echo the result if verbose

+ -- Reads an rpm variable. Unlike a basic rpm.expand("{?foo}"), returns nil if

+ -- the variable is unset, which is convenient in lua tests and enables

+ -- differentiating unset variables from variables set to ""

+ local function read(rpmvar)

+   if not rpmvar or

+     (rpm.expand("%{" .. rpmvar .. "}") == "%{" .. rpmvar .. "}") then

+     return nil

+   else

+     return rpm.expand("%{?" .. rpmvar .. "}")

+   end

+ end

+ 

+ -- Returns true if the macro that called this function had flag set

+ --   – for example, hasflag("z") would give the following results:

+ --     %foo -z bar → true

+ --     %foo -z     → true

+ --     %foo        → false

+ local function hasflag(flag)

+   return (rpm.expand("%{-" .. flag .. "}") ~= "")

+ end

+ 

+ -- Returns the argument passed to flag in the macro that called this function

+ --  – for example, readflag("z") would give the following results:

+ --      %foo -z bar → bar

+ --      %foo        → nil

+ --      %foo -z ""  → empty string

+ --      %foo -z ''  → empty string

+ local function readflag(flag)

+   if not hasflag(flag) then

+     return nil

+   else

+     local a = rpm.expand("%{-" .. flag .. "*}")

+     -- Handle "" and '' as empty strings

+     if (a == '""') or (a == "''") then

+       a = ''

+     end

+     return a

+   end

+ end

+ 

+ -- Sets a spec variable; echoes the result if verbose

  local function explicitset(rpmvar, value, verbose)

    local value = value

    if (value == nil) or (value == "") then
@@ -9,31 +48,29 @@ 

    end

    rpm.define(rpmvar .. " " .. value)

    if verbose then

-     rpm.expand("%{echo:Setting %%{" .. rpmvar .. "} = " .. value .. "}")

+     rpm.expand("%{warn:Setting %%{" .. rpmvar .. "} = " .. value .. "}")

    end

  end

  

- -- Unset a spec variable if it is defined

- -- Echo the result if verbose

+ -- Unsets a spec variable if it is defined; echoes the result if verbose

  local function explicitunset(rpmvar, verbose)

    if (rpm.expand("%{" .. rpmvar .. "}") ~= "%{" .. rpmvar .. "}") then

      rpm.define(rpmvar .. " %{nil}")

      if verbose then

-       rpm.expand("%{echo:Unsetting %%{" .. rpmvar .. "}}")

+       rpm.expand("%{warn:Unsetting %%{" .. rpmvar .. "}}")

      end

    end

  end

  

- -- Set a spec variable, if not already set

- -- Echo the result if verbose

+ -- Sets a spec variable, if not already set; echoes the result if verbose

  local function safeset(rpmvar, value, verbose)

    if (rpm.expand("%{" .. rpmvar .. "}") == "%{" .. rpmvar .. "}") then

      explicitset(rpmvar,value,verbose)

    end

  end

  

- -- Alias a list of rpm variables to the same variables suffixed with 0 (and vice versa)

- -- Echo the result if verbose

+ -- Aliases a list of rpm variables to the same variables suffixed with 0 (and

+ -- vice versa); echoes the result if verbose

  local function zalias(rpmvars, verbose)

    for _, sfx in ipairs({{"","0"},{"0",""}}) do

      for _, rpmvar in ipairs(rpmvars) do
@@ -113,13 +150,7 @@ 

    return best

  end

  

- -- https://github.com/rpm-software-management/rpm/issues/581

- -- Writes the content of a list of rpm variables to a macro spec file.

- -- The target file must contain the corresponding anchors.

- -- For example writevars("myfile", {"foo","bar"}) will replace:

- --   @@FOO@@ with the rpm evaluation of %{foo} and

- --   @@BAR@@ with the rpm evaluation of %{bar}

- -- in myfile

+ -- %writevars core

  local function writevars(macrofile, rpmvars)

    for _, rpmvar in ipairs(rpmvars) do

      print("sed -i 's\029" .. string.upper("@@" .. rpmvar .. "@@") ..
@@ -150,8 +181,9 @@ 

      for word in string.gmatch(line, "%s*[^%s]*\n?") do

        local wl, bad = utf8.len(word)

        if not wl then

-         print("%{warn: Invalid UTF-8 sequence detected in:\n" ..

-                word .. "\nIt may produce unexpected results.\n}")

+         print("%{warn:Invalid UTF-8 sequence detected in:}" ..

+               "%{warn:" .. word .. "}" ..

+               "%{warn:It may produce unexpected results.}")

          wl = bad

        end

        if (pos == 0) then
@@ -182,7 +214,71 @@ 

    return output

  end

  

+ -- Because rpmbuild will fail if a subpackage is declared before the source

+ -- package itself, provide a source package declaration shell as fallback.

+ local function srcpkg(verbose)

+   if verbose then

+     rpm.expand([[

+ %{echo:Creating a header for the SRPM from %%{source_name}, %%{source_summary} and}

+ %{echo:%%{source_description}. If that is not the intended result, please declare the}

+ %{echo:SRPM header and set %%{source_name} in your spec file before calling a macro}

+ %{echo:that creates other package headers.}

+ ]])

+   end

+   print(rpm.expand([[

+ Name:           %{source_name}

+ Summary:        %{source_summary}

+ %description

+ %wordwrap -v source_description

+ ]]))

+   set("currentname", "%{source_name}", verbose)

+ end

+ 

+ -- %new_package core

+ local function new_package(source_name, pkg_name, name_suffix, first, verbose)

+   -- Safety net when the wrapper is used in conjunction with traditional syntax

+   if (not first) and (not source_name) then

+     rpm.expand([[

+ %{warn:Something already set a package name. However, %%{source_name} is not set.}

+ %{warn:Please set %%{source_name} to the SRPM name to ensure reliable processing.}

+ ]])

+     if name_suffix then

+       print(rpm.expand("%package        " .. name_suffix))

+     else

+       print(rpm.expand("%package     -n " .. pkg_name))

+     end

+     return

+   end

+   -- New processing

+   if not (pkg_name or name_suffix or source_name) then

+     rpm.expand([[

+ %{error:You need to set %%{source_name} or provide explicit package naming!}

+ ]])

+   end

+   if name_suffix then

+     print(rpm.expand("%package        "  .. name_suffix))

+     set("currentname", "%{source_name}-" .. name_suffix, verbose)

+   else

+     if not source_name then

+       source_name = pkg_name

+     end

+     if (pkg_name == source_name) then

+       safeset("source_name", source_name, verbose)

+       print(rpm.expand("Name:           %{source_name}"))

+     else

+       if source_name and first then

+         srcpkg(verbose)

+       end

+       print(rpm.expand("%package     -n " .. pkg_name))

+     end

+     set("currentname", pkg_name, verbose)

+   end

+ end

+ 

  return {

+   read          = read,

+   hasflag       = hasflag,

+   readflag      = readflag,

    explicitset   = explicitset,

    explicitunset = explicitunset,

    safeset       = safeset,
@@ -194,4 +290,5 @@ 

    getbestsuffix = getbestsuffix,

    writevars     = writevars,

    wordwrap      = wordwrap,

+   new_package   = new_package,

  }

file modified
+20 -18
@@ -1,16 +1,16 @@ 

- # Some miscellaneous Fedora-related macros

+ # Fedora macros, safe to use after the SRPM build stage

  

- # List files matching inclusion globs, excluding files matching exclusion blogs

- # Optional parameters:

- #  – -i "<globs>" inclusion globs

- #  – -x "<globs>" exclusion globs

- # Globs are space-separated lists of shell globs. Such lists require %{quote:}

- # use for safe rpm argument passing.

- # Alternatively, set the following rpm variables before calling the macro:

- #  – “listfiles_include” inclusion globs

- #  — “listfiles_exclude” exclusion globs

- # Arguments passed to the macro without flags will be interpreted as inclusion

- # globs.

+ # Lists files matching inclusion globs, excluding files matching exclusion

+ # globs

+ #   – globs are space-separated lists of shell globs. Such lists require

+ #     %{quote:} use when passed as rpm arguments or flags.

+ # Control variables, flags and arguments:

+ #   %{listfiles_include}  inclusion globs

+ #   %{listfiles_exclude}  exclusion globs

+ #   -i <globs>            inclusion globs

+ #   -x <globs>            exclusion globs

+ #   …                     arguments passed to the macro without flags will be

+ #                         interpreted as inclusion globs

  %listfiles(i:x:) %{expand:

  %if %{lua: print(string.len(rpm.expand("%{?-i*}%{?listfiles_include}%*")))}

    listfiles_include=$(realpath -e --relative-base=. %{?-i*} %{?listfiles_include} %* | sort -u)
@@ -26,12 +26,14 @@ 

  }

  

  # https://github.com/rpm-software-management/rpm/issues/581

- # Write the contents of a list of rpm variables to a macro file.

- # The target file must contain the corresponding anchors.

- # For example %writevars -f myfile foo bar will replace:

- #  @@FOO@@ with the rpm evaluation of %{foo} and

- #  @@BAR@@ with the rpm evaluation of %{bar}

- # in myfile

+ # Writes the contents of a list of rpm variables to a macro file

+ # Control variables, flags and arguments:

+ #   -f <filename>  the macro file to process:

+ #                    – it must contain corresponding anchors

+ #                    – for example %writevars -f myfile foo bar will replace:

+ #                        @@FOO@@ with the rpm evaluation of %{foo} and

+ #                        @@BAR@@ with the rpm evaluation of %{bar}

+ #                      in myfile

  %writevars(f:) %{lua:

  local    fedora = require "fedora.common"

  local macrofile = rpm.expand("%{-f*}")

file modified
+28 -7
@@ -1,4 +1,4 @@ 

- # Some miscellaneous Fedora-related macros

+ # Fedora macros, safe to use at SRPM build stage

  

  # A directory for rpm macros

  %rpmmacrodir /usr/lib/rpm/macros.d
@@ -10,13 +10,34 @@ 

  # A directory for SWID tag files describing the installation

  %_swidtagdir %{_prefix}/lib/swidtag/fedoraproject.org

  

- # A helper to apply the fedora.wordwrap filter to the content of an rpm

- # variable, and print the result. Optional parameter:

- #  – -v <variable_name> (default value: _description)

- # Putting multiple lines of UTF-8 text inside a variable is usually

- # accomplished with a %%{expand: some_text}.

+ # Applies the fedora.wordwrap filter to the content of an rpm variable, and

+ # prints the result.

+ #   – putting multiple lines of UTF-8 text inside a variable is usually

+ #     accomplished with %{expand:some_text}

+ # Control variables, flags and arguments:

+ #   -v <variable_name>  (default value: _description)

  %wordwrap(v:) %{lua:

  local   fedora = require "fedora.common"

- local variable = "%{" .. rpm.expand("%{-v*}%{!-v:_description}") .. "}"

+ local variable = "%{?" .. rpm.expand("%{-v*}%{!-v:_description}") .. "}"

  print(fedora.wordwrap(variable))

  }

+ 

+ # A single Name: and %package substitute

+ # Control variables, flags and arguments:

+ #   %{source_name}         the SRPM name

+ #   %{source_summary}      the SRPM summary

+ #   %{source_description}  the SRPM description

+ #   -n <name>              declare a package named <name>

+ #                          (%package-like behavior)

+ #   -v                     be verbose

+ #   %1                     declare a package named %{source_name}-%{%1}

+ #                          (%package-like behavior)

+ %new_package(n:v) %{lua:

+ local      fedora = require "fedora.common"

+ local    pkg_name = fedora.readflag("n")

+ local     verbose = fedora.hasflag("v")

+ local name_suffix = fedora.read("1")

+ local source_name = fedora.read("source_name")

+ local       first = not ( fedora.read("name") or fedora.read("currentname") )

+ fedora.new_package(source_name, pkg_name, name_suffix, first, verbose)

+ }

file modified
+42 -57
@@ -1,50 +1,28 @@ 

- # Map forge information to rpm metadata. This macro will compute default spec

- # variable values.

- #

- # The following spec variables SHOULD be set before calling the macro:

- #

- #   forgeurl  the project url on the forge, strongly recommended;

- #   Version   if applicable, set it with Version: <version>

- #   tag       if applicable

- #   commit    if applicable

- #   date      if applicable (to override the mtime of the Source archive)

- #

- #  Use -z for multiple calls to the macro

- #

- # The macro will attempt to compute and set the following variables if they are

- # not already set by the packager:

- #

- #   forgesource    an URL that can be used as SourceX: value

- #   forgesetupargs the correct arguments to pass to %setup for this source

- #                  used by %forgesetup and %forgeautosetup

- #   archivename    the source archive filename, without extentions

- #   archiveext     the source archive filename extensions, without leading dot

- #   archiveurl     the url that can be used to download the source archive,

- #                  without renaming

- #   topdir         the source archive top directory (can be empty)

- #   extractdir     the source directory created inside %{_builddir} after using

- #                  %%forgesetup, %forgeautosetup or %{forgesetupargs}

- #   repo           the repository name

- #   owner          the repository owner (if used by another computed variable)

- #   shortcommit    the commit hash clamping used by the forge, if any

- #   scm            the scm type, when packaging code snapshots: commits or tags

- #   distprefix     the prefix that needs adding to dist to trace non-release packaging

- #

- # Most of the computed variables are both overridable and optional.

- #

- # Optional parameters:

- #   -a          process all sources in one go, instead of using separate -z calls

- #   -z <number> suffix all the read and written variable names with <number>

- #               for example read     forgeurl<number>, version<number>…

- #                       and generate forgesetupargs<number>, archiveurl<number>…

- #               The macro assumes that null or nil suffix is used for the primary

- #               package source.

- #   -s  Silently ignore problems in forgeurl, use it if it can be parsed,

- #       ignore it otherwise.

- #   -v  Be verbose and print every spec variable the macro sets.

- #   -i  Print some info about the state of spec variables the macro may use or

- #       set at the end of the processing.

- %forgemeta(az:sviu:) %{lua:

+ # Computes forge-related variables for use in the rest of the spec file

+ # Control variables, flags and arguments:

+ #   %{forgeurl<number>}  the project url on the target forge

+ #   %{tag<number>}       the packaged tag, OR

+ #   %{commit<number>}    the packaged commit, OR

+ #   %{version<number>}   the packaged version

+ #                          – %{version}/%{version0} are set via:

+ #                              Version:

+ #                          – because git is lacking a built-in version

+ #                            reference, %{version<number>} will be translated

+ #                            into %{tag<number>} using unreliable heuristics;

+ #                            set %{tag<number>} directly if those fail

+ #   %{date<number>}      the packaged timestamp

+ #   …                    %forgemeta will compute a huge number of variables:

+ #                          — the packager can override it by setting some of

+ #                            those before the %forgemeta call

+ #                          – use the -i flag to list those variables

+ #   -z <number>          only process the zth block of definitions

+ #                        "" for the no-suffix block

+ #   -i                   list the resulting variable values

+ #   -s                   silently ignore problems in %{forgeurl<number>}

+ #   -v                   be verbose

+ #   -a                   process all sources in one go, instead of using

+ #                        separate -z calls

+ %forgemeta(z:isva) %{lua:

  local      fedora = require "fedora.common"

  local       forge = require "fedora.srpm.forge"

  local     verbose =  rpm.expand("%{-v}") ~= ""
@@ -60,12 +38,17 @@ 

  end

  }

  

- # Convenience macro to relay computed arguments to %setup

- # Optional parameters:

- #   -a          process all sources in one go, instead of using separate -z calls

- #   -z <number> read %{?forgesetupargs<number>}

- #   -v          be verbose

- %forgesetup(az:v) %{lua:

+ # Unpacks sources computed by %forgemeta

+ # Control variables, flags and arguments:

+ #   %{forgesource<number>}       the source archive that will be processed

+ #   %{forgesetupargs<number>}    %setup arguments

+ 

+ #   -z <number>                  only process the zth block of definitions

+ #                                "" for the no-suffix block

+ #   -v                           be verbose

+ #   -a                   process all sources in one go, instead of using

+ #                        separate -z calls

+ %forgesetup(z:va) %{lua:

  local fedora = require "fedora.common"

  if (rpm.expand("%{-z}") == "") and (rpm.expand("%{-a}") ~= "") then

    for _,s in pairs(fedora.getsuffixes("forgesetupargs")) do
@@ -76,10 +59,12 @@ 

  end

  }

  

- # Convenience macro to relay computed arguments to %autosetup

- # Parameters relayed to %autosetup: -v -N -S -p

- # Optional parameters:

- #   -z <number> read %{?forgesetupargs<number>}

+ # Calls %autosetup using %forgemeta results

+ #   – this will probably be removed since it is unsafe in presence of multiple

+ #     sources

+ # Control variables, flags and arguments:

+ #   -z <number>  process the zth block of definitions

+ #   -v -N -S -p  relayed to %autosetup

  %forgeautosetup(z:vNS:p:q) %{lua:

  print(rpm.expand("%autosetup %{-v} %{-N} %{?-S} %{?-p} %{?forgesetupargs" .. rpm.expand("%{-z*}") .. "}\\n"))

  }

Formely, one would write

%package -n foo

for a sub-package header in the spec preamble, and

Name: foo

for the SRPM header. %{name} could not be used (in SourceX, PatchX, etc) before the Name: line, and may contain something else than the SRPM name after a subpackage header.

With the PR, one may use:

%newpackage -n

all the time and set %{source_name} before any %newpackage line if it needs it for other things. If %source_name is not set by the packager it is set by the first %newpackage call.

A bare

%new_package

call is equivalent to

%new_package -n %{source_name}

ie

Name: %{source_name}

if %{source_name} is already set.

In other words, %new_package is a single package declaration verb, that behaves the same way all the time without artificial SRPM vs non SRPM distinctions. That‘s the common way rpm verbs behave today (in %files, %description, etc). Name: vs %package is just historical rpm cruft.

Because designing strict variable declaration ordering is hard for complex packages, they should define sources and patches in %sourcelistand %patchlist, after the preamble, instead of constructing complex SourceX:/PatchX within the spec preamble. %new_package helps handling %{name} ordering but does nothing for other preamble variables.

This is the result of workarounding Fedora problems created by rpm commit 93604e2

(backwards-incompatible)

🐞 See also:
https://github.com/rpm-software-management/rpm/issues/1161
https://pagure.io/packaging-committee/issue/968
https://bugzilla.redhat.com/show_bug.cgi?id=1820349
https://bugzilla.redhat.com/show_bug.cgi?id=564613

🐞 This is a “Minimal” workaround that keeps Fedora spec files building but
does not actually fix the ordering problems in Sources/Patches that break
Fedora CI & spectool. The rpm parser now imposes ordering constrains while
making impossible to declare Source files at the point those constrains
could be resolved, just before %prep

🐞 Use of this will create backwards-incompatible spec files. This is imposed by
the rpm parser own lack of backwards incompatibility (TANSTAAFL).

rpm maintainers refused to own

I think such horrible language is no-go here.

I think this should be Workaround worlds problems created by nim

I don't understand what are you trying to do here. Please:

  • remain respectful
  • fix the affected packages

ordering problems in Sources/Patches that break Fedora CI & spectool.

I kept asking for reproducers because I'm not seeing any breakage. There isn't a single mention of either CI or spectool anywhere in the bug you filed, and now that I go specifically looking, a passing mention of Fedora CI in the upstream ticket with no specifics.

The rpm parser now imposes ordering constrains while making impossible to declare Source files at the point those constrains could be resolved, just before %prep

Sigh. There's no such ordering constraint introduced. The only constraint is to use already defined macros, not any tag ordering.

Use of this will create backwards-incompatible spec files. This is imposed by
the rpm parser own lack of backwards incompatibility

Um. What exactly is supposed to be backwards incompatible here? I don't claim to understand the commit, but it looks to be about declaring a macro beforehand and using that to get around the weird placing of Name:, which is what I suggested as the proper resolution to this. There's absolutely nothing incompatible about that.

I kept asking for reproducers because I'm not seeing any breakage.

I took the time to report the breakage I hit, that was dismissed as packager mistakes.

When it become clear you had zero intention of understanding the situation and investigating a general fix, I took the time to comb the 4-digit mass of affected specs to find 2 spec files that were both generic enough and simple enough and comparable enough they could serve as testcases for a generalised solution. I tested various Source declaration orders, and reported the errors I hit. That was dismissed as too much data.

I then took the time to give you the exact line numbers (with a direct pointer to the corresponding spec lines on src.fedoraproject.org). That was further ignored. From then on you refused both to acknowledge any of the fix attempts I did on those spec files, and to try your hand on them yourself (I even gave you the requirements that made it possible for a fix to be generalised).

I also took the time to list all the potential ways I saw to get things to work, both without any change to existing spec files, and with a reasonable complexity packager side, so you did not have to manipulate spec files you were uncomfortable with. I even offered to take most of the downstream fallout burden on myself as long as you contributed the upstream rpm part of this fixing.

Several of those ways did not require backing out the rpm change. They did require fixing the problems that were work-arounded more than 10 years ago with the syntax the rpm change casually invalidated. Reminding 10 years-old requests to fix rpm limitations to remove the need for a lot of complexity downstream was dismissed. (I won’t list all the work involved in re-discovering, re-visiting and re-investigating 10 years later all the problems that led to the original workaround).

You then closed the discussion with “advice”, and backed away when challenged to put this advice in practice.

So, once again, I did the work you had no intention of doing and implemented your own design in this PR. With full understanding of the implications (astonishing, the level of understanding one can attain by actually doing things).

What exactly is supposed to be backwards incompatible here?

Existing specs won’t build without further spec level changes. Changed specs won’t build on past releases without backporting the redhat-rpm-config changes to past releases (which would make past unchanged specs break on rebuild). Also, there will be zero practical win compared to the situation that existed before the rpm change, and spec file structure will get more complex.

But, the constrains the rpm change forces downstream will be applied, and packagers will recover the ability to declare patches in the affected spec files without instant build failure.

The dirty laundry over an rpm upstream change doesn't belong here, so I'll just note that there are two sides to every story, ours seem remarkably different. I still think there's some fundamental misunderstanding getting lost in the noise and agitation over assumptions that you're making about my intentions. I refuse to continue this sort of "discussion".

Existing specs won’t build without further spec level changes. Changed specs won’t build on past releases without backporting the redhat-rpm-config changes to past releases (which would make past unchanged specs break on rebuild).

Right, incompatibility with this macro ecosystem. I wouldn't sacrifice such a thing over the ability to use %{name} in a source/patch (which is the wrong, if common, thing to begin with).

Oh, just one more remark: what you asked for as the "clean" solution, to add SourceName: or similar to rpm itself would render those specs incompatible for the rest of the world, for the sake of defining one macro that you can manually define in every single existing rpm version out there. That's simply a bad deal. As it is, you can backport this at your will.

  1. you committed a 30-lines rpm change
  2. you did not do any significant work to deal with the consequences
  3. dealing with the consequences in 1500+ packages will cost at least 3 to 4 000 lines of changes in 1 500+ separate repositories from multiple Fedora contributors

So to hell with all your repeated disrespectful dismissal of other people’s work.

Where are the links to the failed builds?

@ffesti

The problem was identified after adding a Patch line to dejavu-fonts with usual Fedora conventions¹ directly bombed out. Investigation revealed it was caused by a backwards-incompatible rpm 4.15 change.

Now dejavu-fonts is part of an ecosystem of ~1600 Fedora packages that use the same Source/Patches declaration order. It is not sufficient to hack up a quick and dirty fix in this spec file. A generic solution needs to be found for the ~1600 spec file set.

Right now this set is in early bring out mode². Problem upstream material is not fixed by clean patching it is brutally removed in %prep. dejavu-fonts is a bit of an outlier in reaching maturity early. That is probably why the problems caused by the rpm change were identified so late. There was (and still is) a time windows during which most of the patches had been removed from the package set.

However, the target is to ultimately get this ~1600 package set up to usual Fedora standards, which mean retaining normal no-hassles patching ability.

The package set uses two closely aligned packaging patterns, showcased in:
https://src.fedoraproject.org/rpms/sil-mondulkiri-fonts/blob/master/f/sil-mondulkiri-fonts.spec
https://src.fedoraproject.org/rpms/sil-mondulkiri-extra-fonts/blob/master/f/sil-mondulkiri-extra-fonts.spec

The only difference is that in the first case, the srpm naming is inherited from one of the functional subpackages, and in the other case, upstream did not named itself after one of the published components. I took fonts spec examples because you do not need to deal with the Go toolchain crazyness to understand the problem.

The patterns are deliberately kept as close as possible (at the spec diff level). Packagers are expected to cut and paste from one spec type to the other, and a package can transition from one state to the other during its lifetime³.

So, there is a need to find a Source/Patch declaration mode that is as close as possible (ideally, identical) between the two patterns, and lets packagers do their usual packaging work (adding new sources and patches next to the provious ones, reusing %{name} and other variables in source and patch naming, etc).

From a spec workflow POW, those specs really want Source/Patch evaluation to be done as late as possible, because Source and Patch tend to reuse variables declared or calculated as part of the rest of the preamble. So, their ideal declaration syntax would be to stick the Source/Patch lines just before %prep.

That has not been possible so far due to rpm parser limitations.

However, things still worked fine, because the rpm parser did not stop evaluating Source/Patch at their declaration point. The rpm change broke this setup by removing those later evaluations.

¹ That use %{name}, ~ 14 000 Fedora uses of %{name} in sources without counting patch declarations right now

² 2 years old for Go packages, six months old for fonts, with packagers getting a bit crazy from burnout.

³ For example, golang-github-prometheus will be renamed to plain prometheus once we finish beating prometheus-the-application into shape, not worth the hassle given the state it is in right now

The problem was identified after adding a Patch line to dejavu-fonts with usual Fedora conventions (that use %{name}) directly bombed out.

So it wasn't even a regression? And even then, using %{name} in Patch: really does not sound like a compelling case to me. Some packages use it, but since patch names need not be unique across the entire distribution, I find it more than confusing than useful.

I've been rather critical of past RPM changes, but I must say that this whole pull request is rather confusing in its direction.

This change would also be much easier to review if the comments and the commit message had actually useful information like: What does the patch actually achieve, where, how and why is this macro actually used.

It looks like all it does is (re?) expanding the source list right after it creates the Name: tag. But it seems to be deeply built into the font macros which are not even mentioned. Or is this new macro to be added to 1500 packages by hand? Where's the benefit in that?

And even then, using %{name} in Patch: really does not sound like a compelling case to me. Some packages use it, but since patch names need not be unique across the entire distribution, I find it more than confusing than useful.

Use of %{name} in everywhere including Patch and Source is this strange bad habit that generations of packagers (including myself) have been subliminally conditioned to by copying what others do: "it's a macro so it must be somehow better." It entirely nonsensical because pre-existing file names such as patches/sources are not derived from Name: at package build time, so it'll just unnecessarily break if package is renamed. It's also far more cumbersome to type than copy-paste the literal filename of eg a patch. So it's literally just jumping through extra hoops to make it wrong.

The problem was identified after adding a Patch line to dejavu-fonts with usual Fedora conventions (that use %{name}) directly bombed out.

So it wasn't even a regression?

It was a regression, that did not trigger at the time it was introduced, due to a specific moment of the project when affected packages where free of patches for other reasons

And even then, using %{name} in Patch: really does not sound like a compelling case to me.

There are ~14 000 uses of %{name} in sources right now (the patch count was not done). Changing packager habits would be a major endeavour

Some packages use it, but since patch names need not be unique across the entire distribution, I find it more than confusing than useful.

BTW the rpm change also broke

 %_sourcedir %{_topdir}/SOURCES/%{name}

that some packagers were using to segment ~/rpmbuild/SOURCES/ by package and avoid the need of explicit patch prefixing (since, the prefixing never worked when upstreams chose identical source names)

This change would also be much easier to review if the comments and the commit message had actually useful information like: What does the patch actually achieve, where, how and why is this macro actually used.

You can see it in use in
https://copr.fedorainfracloud.org/coprs/nim/workaround-rpm-commit-93604e2-effects/builds/

Rinse repeat for every clean font package in the distribution (there are some leftovers of previous packaging macros that also suffer from the same rpm regression, I’m not going to change those, the previous stuff had already been deprecated).

I’ve not made the corresponding change Go-side yet. It is several orders more complex and requires a lot of care to avoid breaking things. It will require the same spec-level changes in every single Go spec in Fedora.

It looks like all it does is (re?) expanding the source list right after it creates the Name: tag.

It expands manually to replace the expansions rpm upstream removed. Though, not at the correct functional point. The correct functional point would be the %prep line but that is not something a macro can do

The whole design has been dropped on my ecosystems by the rpm change owner, so I’m not the right person to defend it.

https://pagure.io/packaging-committee/issue/968#comment-641830

But it seems to be deeply built into the font macros which are not even mentioned. Or is this new macro to be added to 1500 packages by hand?

It will need manual changes in all the 1500 packages, to make them conform to the Name/Source/Patch ordering required by the rpm change. I’ve tried to limit it to the minimum but I’m no magician to replace built-in rpm behaviour with macro emulation without any spec change.

Where's the benefit in that?

This PR is a pure damage limitation exercise to restore the situation where packagers could perform normal maintenance tasks on their specs without weird failures that can not be handled without heavy specialist surgery. It would not need to exist without the rpm change. Anyone who objects to the PR is free to take the “resolution” handed down by the rpm change owners and try to apply it to the affected spec pool in some less invasive way. I won’t mind, it’s not my mess in the first place.

From the packager side of the equation, the whole thing is negative (if, less negative than years of packagers hitting errors, at the usual murphy-esques most inconvenient times — for example emergency release or security patching).

I’m sure there is some benefit rpm side to make it up for all this.

I’ve not made the corresponding change Go-side yet. It is several orders more complex and requires a lot of care to avoid breaking things. It will require the same spec-level changes in every single Go spec in Fedora.

And, I see now the Go macro code is older and less regular in this area than the Fonts macro code, so making use of this PR to workaround the rpm regression will also require quite a lot of dangerous code restructuring. Sigh.

And the "fix" is not sufficient font side either, will need even more spec by spec surgery.

Right now the extent of the fallout (assuming this PR is merged) is:
– at least 5 lines changed per spec where srpm name ≠ subpackage name
– at least 3 lines changed per spec where srpm name = subpackage name

Most (but not all) Go packages are in the first category. Most (but not all) font packages are in the second category. That make it more than 7200 spec lines to be changed in Fedora devel as latest damage count. Manual changes, because declaration order is now significant and needs to be evaluated by a human. And, I am definitely NOT doing those myself. The responsible people can tell Fedora packagers how great their change is themselves.

Nor counting other reorderings, release bumping and changelog-ing

Not counting the time I spend restructuring the Fedora macro set (but, everyone knows my time is free, and I have nothing else to do for Fedora or outside Fedora).

It was so hard to revert the rpm change once the problem was identified. Or make rpm evaluate Source/Patches at %prep time (the correct functional behaviour). Or provide a working description closing statement so the whole spec pool could be fixed once and for all to apply new rpm rules by adding

%close_description

before %prep and moving Source/Patch declarations in bulk between those two lines with a few greps or seds.

All this is going straight to devel once the workaround patterns are finished, with FW rpm maintainers if anyone complains.

Subscribe

I find it absolutely fascinating how little tangible technical information there is in this PR and all the related ticket. One would think with all the hours of analysis of thousands of packages there would be a few concrete pointers.
While we do know the number of lines all these changes have somehow it is not possible to attach the diff somewhere. There is still not a single build error on an unchanged package to be seen and while surely someone has analysed why things break there is no report that points to actual point in the spec file - or the font or go macros - that cause the breakage.
Some people seem to think it is enough to drop some package name and have people like me dig through multiple layers of macro definitions. Or to just drop a patch with a list of of links to inconclusive tickets as an explanation. It is not.

I agree completely. Based on the information presented here, I would have expected that bcache-tools fails to build in rawhide because it has Source0: %{name}-%{version}.tar.gz and Patch0: %{name}-status-20160804-man.patch in its spec file, but that does not seem to be the case.
Without a single build failure in Koji, it is hard to figure out what is going on here.

To recap once again.

Historic relied-upon rpm behaviour

rpm used to evaluate Sources and Patches at logical use time (when the SRPM is assembled), not just at declaration time.

This effectively meant you could safely use any rpm variable declared or computed in the rpm preamble in sources and patches, regardless of whether this variable was computed/set before or after the SourceX/PatchX line.

Why this was relied upon

Since computing variables can occur as part of computing the lines that make up a package header declaration, declaring sources and patches after the variables are defined, in a generic simple way, without complex spec black magic, requires putting those lines after the last package header block.

Except you can not, because the description of the last package header block will eat any follow-up. The only way to close a description in the preamble without closing the preamble is to start a new package header block, that will itself require a description. Rince, repeat, you end up putting sources and patches before the package headers to get out of recursive rpm parser assertion hell.

It is not possible to interleave simply Source/Patches lines the rest of package headers in automation. Automation (ie macros) is all about local processing, without a holistic view of what other macros and manual spec statements are doing in the preamble. Hand-crafted spec-specific magic interleaved orderings require a human for the hand-crafting.

It is not possible to ignore that header declarations create or set rpm variables. One such magic, widely used variable, %{name}, is created as part of one of the package headers. %{name} is not the sole variable created as part of package headers that may end up in sources or patches BTW, just the most common one everyone knows about.

Extent of the damage

Providing a sane way to explicitly close rpm descriptions had already been requested 10 years ago in
https://bugzilla.redhat.com/show_bug.cgi?id=564613

That’s how long the rpm limitations had been identified and workarounded by moving source and patch lines before preamble header blocks.

rpm commit 93604e2 removes evaluation of sources/patches after the source/patch lines.

It now makes unsafe, any Fedora spec that computes or sets variables after the Source/Patch lines, if those variables can end up in Source/Patches. That includes all the Fedora fonts and go spec files. 2 autonomous Fedora macro ecosystems, 7% of the distribution, including packages required by Fedora default composes. The unsafety does not trigger immediately, but once the packager needs to use one of those variables in his spec or build environment. rpm will now insult him and require rewriting the preamble logic to fit its new assumptions.

Therefore, the rpm change is especially nasty, because of its delayed effects. Once you hit the effect you need a full preamble rewrite of things that may have been working fine for years.

If you do not want to audit manually 1500+ spec files, just check
https://src.fedoraproject.org/rpms/sil-mondulkiri-fonts/blob/master/f/sil-mondulkiri-fonts.spec
https://src.fedoraproject.org/rpms/sil-mondulkiri-extra-fonts/blob/master/f/sil-mondulkiri-extra-fonts.spec

which are representative of those 1500+ Fedora spec files (check the 1500+ spec files yourself if you do not trust me here).

If you do not want to read and understand the whole macro logic used in here, read variable ordering in the unprocessed spec file, and the result after rpmspec -P. And, remember that the %fontpkg (or %gopkg) line computes and sets rpm variables that are supposed to be available for Source/Patch use.

I will not provide contrived simplified spec files just so people can argue to death about simplistic patterns till they have no relation at all with what Fedora packages actually do. I deal with real Fedora packages, not unicorn abstractions. Analyse existing Fedora spec files yourself, or STFU and accept my technical analysis.

rpm maintainers resolution

https://pagure.io/packaging-committee/issue/968#comment-641830

Content of this PR

This PR automates the design provided by rpm maintainers. Read this design and tell me where the macro code diverge if you disagree. Complain to design authors if this design does not match your standards.

It provides the core over which the black magic heavy surgery required by the rpm change can be built upon. As stated before, it is not possible to conform to the Source/Patch ordering requirements of the rpm change, without complex logic, and inter-macro holistic preamble coordination (provided in this PR).

PR applications

Because the PR only provides the generic part of the changes required by rpm breaking compat, the rpm change also requires heavy rework of domain-specific macros to use this PR and make sure all preamble variables are computed and set before the new Source/Patch evaluation point.

This is done for fonts in fonts-rpm-macros 3.0.1 (3.x because it breaks compat, 3.0.1 because it took, so far, two releases to workaround the rpm change; there will be a 3.0.2 to further fix the default templates).
https://pagure.io/fonts-rpm-macros/c/4c76c857e3918006d2ca00a1bf5b60a4164e504b..a60b1d2c0216808e67f7d597583cc7407fa83c03

As stated before, using the new macro design requires at least 3 to 5 lines of changes in every existing font spec. I expect the damage to be similar go spec side once I’ve finished coding a similar restructuring there. You have some converted spec builds here:
https://copr.fedorainfracloud.org/coprs/nim/workaround-rpm-commit-93604e2-effects/builds/

You can compare those build with the previous koji builds, diff the specs, trace the changes, whatever makes you feel good about it (it did not make me feel good about it). You will hopefuly find that every preamble variable is not set before the Source/Patch lines.

I won’t convert more font specs myself and I’m most definitely not converting the 1200+ go spec files once the go-rpm-macros rewrite will require similar changes in go spec files. As stated before, the go-rpm-macro change will be a lot more tricky because go requirements are more complex than font requirements, and the macro codebase is older and less clean.

Distribution-level breakage

Since people have repeatedly asked to see distribution breakage before they condescend looking at the problem, I’ve now pushed and built fonts-rpm-macros 3.0.1 in koji. fonts-rpm-macros 3.0.1 depends on this PR.

https://koji.fedoraproject.org/koji/taskinfo?taskID=43878778

Therefore, very single cleaned up font package now FTBS in devel, and (depending on how long it takes for the FTBS to result in orphaning) the Fedora editions that use fonts no longer compose.

Let me get this straight: there was no evidence of the claimed mass-breakage from said rpm change from the last 10 months its been in Fedora you could point us to, so you introduced this rather elaborate change to deliberately break things? Oookkaay...

Let me get this straight: you were not interested in analysing the problem you created despite being pointed to real world packages, and gave a take it or leave it resolution that you did not bother implementing, despite being told repeatedly actually implementing it would be horribly complex.

So, now I did your work. Thank you nim for spending a few weeks of coding implementing my idea. Sorry nim I did not think things through and did not bother to measure the implications of my change. Sorry nim I did not bother to measure the implications of the "resolution" I closed the discussion with.

Now the change is half done (the go part is still to be finished). Deal with it.

despite being pointed to real world packages

Yes, you pointed us to couple of packages that were building just fine, and evidently had been doing so all along. Which kinda contradicts with my definition of being broken. And hence this strange loop.

We do not think a problem exists in Fedora rawhide as of today because as far as we know, there are no build failures. Showing us the rawhide build failures would help your case a lot. It is extremely puzzling to us why you claim that there is mass-breakage, but you cannot show us evidence of any such breakage (preferably in the form of Fedora rawhide build failures).

@fweimer The whole thing started with a build failure
https://bugzilla.redhat.com/show_bug.cgi?id=1820349

Not interested rehashing one more time that the affected spec is part of huge Fedora package set, nor that %{name} is not the only variable those specs use, nor where the variables those spec use are defined and computed. You have
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#comment-42674
for that.

The change makes Source/Patch systematically evaluate after the other variables are defined as rpm maintainers insisted is the new only way to do things safely.

Sorry for interrupting the shouting match.

@nim Looking at the font example it seems like the new %sourcelist and %patchlist sections might be just doing what you need. They got added in 4.15 so they are still pretty recent. In my very preliminary testing they could easily be added to right before the %prep section.

@ffesti thank you for the tip, I was not aware of those (I wish I had been before all this recoding), I will look at them right now

@ffesti Quick preliminary testing shows your solution seems to work. And, it was introduced in the same version that broke compat, so there will be a spec compat break but no time windows without a working solution.

Thanks a LOT. I was not looking towards full refactoring of the go macro code.

From a high-level POW, that would change spec structure the following way

  1. for a fully automated spec
%global fontfoo*
…

SourceX: XXX.tar.gz
PatchY:  YYY.patch

%fontpkg

%prep

into

%global fontfoo*
…

%fontpkg

%sourcelist
XXX.tar.gz

%patchlist
YYY.patch

%prep

And for a spec that needs special srpm naming

%global fontfoo*
…

SourceX: XXX.tar.gz
PatchY:  YYY.patch

Name:  foo
…

%fontpkg

%prep

into

%global source_name foo
%global fontfoo*
…

%new_package
…

%fontpkg
%sourcelist
XXX.tar.gz

%patchlist
YYY.patch
%prep

Yes that means I intend to keep this PR as a way to simplify srpm handover between macros. May as well keep something from the whole mess. The mechanism is cleaner and more flexible than what the fonts and go macros used before. However, I will simplify the PR since it no longer needs to play games with source/patch declaration blocks.

Lastly, the fonts specs (but, not the go specs IIRC) were doing things like

%global fontfoo %{SOURCEX}

Since the %sourcelist section does not allow numbering sources explicitly, and asking packagers to count lines is not nice (some of the font packages have huge source lists), this will probably need changing into

%global fontfoo %{_sourcedir}/filename

(not real sure which one is less annoying for packagers). But, that‘s a cheap cost to get rid of 10 years of strange source ordering in specs.

And, again, you solution does not require dangerous refactoring Go macro code that we spent months and thousands of build to test in its current form. Which is a huge benefit. Thank you very much.

And I suppose source_name is inconsistent with %sourcelist, but dnf already implemented a synthetic %{source_name}, therefore I suppose it is better to use identical naming to dnf than invent a slightly different convention.

And even then, using %{name} in Patch: really does not sound like a compelling case to me. Some packages use it, but since patch names need not be unique across the entire distribution, I find it more than confusing than useful.

Use of %{name} in everywhere including Patch and Source is this strange bad habit

I hate this. This makes nice VIM shortcut gf non working :triumph:

rebased onto 60ad6ce4ede43be8f5dfd970fdded5bfbec4b20a

2 years ago

rebased onto 15813359d5aaba243bb02980609cc59a5bff0fc8

2 years ago

rebased onto d66b7a25d7436f5d0ab3ae05bdf1c2eaccf3177a

2 years ago

rebased onto 20baded361554339a7943ad6bf5ad76c1c814519

2 years ago

Anyway, Florian’s suggestion to switch to %sourcelist seems to work, used with this PR to simplify setting the srpm name (thank you @ffesti).

If anyone wants to check the result on this font packages subset for mistakes and other problems:
https://copr.fedorainfracloud.org/coprs/nim/workaround-rpm-commit-93604e2-effects/builds/

Otherwise, let’s just merge this PR, and backport it to FC31/FC32, so we can keep the same packaging templates working across Fedora releases.

Modification of Go macros, spec templates and specs to make them safe WRT rpm 4.15 changes should be a lot less expensive than in this set of font packages.

First, the use of %sourcelist removes the need to rework Go macro code flows, like I did for fonts macros.

Second, Go sources are not full of Fedora-created fontconfig files, that get reordered by the switch to %sourcelist.

That leaves just moving sources & patches to %sourcelist & %patchlist, and search & replace of Name: and %package lines with %new_package (with the latest safety checks in this PR not even sure this last part is absolutely necessary, except as a general cleanup).

if this PR is a blocker for using the new fonts packaging guidelines then can I request the owners of this package to have look into broken macros?

Currently font packages are not building at all in rawhide.

@nim I think it would be useful if your commit message (or any part of the PR) included example. E.g.:

Formerly one would this:

Name: foo
Source1: foo.tar.gz

While now this can be replaced by:

%new_patckage "foo", "goo.tar.gz"

or whatever the correct example is.

IOW while you trying to provide quite a lot of description (which is definitely nice), it still takes a lots of exploration how to actually use it, which in turn does not attract anybody to take a look and review.

Also, naming is hard, but the new_package sounds inappropriate IMHO. It does not create any package, it merely initializes some framework.

Also, naming is hard, but the new_package sounds inappropriate IMHO. It does not create any package, it merely initializes some framework.

It seems I was partially wrong in this, because it clearly defines %package at some places, but that does not make the situation simpler, because it appears to do two things at one. Why do you not focus just on the main package and care about subpackages on different place?

Also, naming is hard, but the new_package sounds inappropriate IMHO. It does not create any package, it merely initializes some framework.

It seems I was partially wrong in this, because it clearly defines %package at some places, but that does not make the situation simpler, because it appears to do two things at one. Why do you not focus just on the main package and care about subpackages on different place?

Because technically, the spec code generated macro side is 100% identical in both cases. You generate a %package -n all the time, except for the SRPM exception that needs a Name:. And there are zero differences in the generated spec code except for %package -n vs Name:.

https://pagure.io/fonts-rpm-macros/blob/master/f/rpm/lua/srpm/fonts.lua#_134

That block also creates the SRPM header for most our fonts packages, there is no SRPM ifdefing in here, %new_package is sufficient to handle the difference and synchronize with the equivalent %gopkg macro for example, if it is also present in the spec file.

The benefit of automating those things for years, with multiple refactoring passes, and thousands of Fedora package builds, is that it makes such non-obvious commonalities clearer

As the safety net in
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#_1__37

shows you could handle the collision just by testing if something already set %{name} but that does not tell you if the current %{name} is the package %{source_name}. That is generally useful information to have. Useful enough:

Of course all that part of the %new_package code (and, probably the faking code dnf side) could be simplified if rpm did set %{source_name} by default. As long as it checks if the packager already set it in the preamble, botched implementation is worse than no implementation at all.

(IMHO, that also shows the SRPM/sub-package boundary in the original rpm data model is not at the place actual 2020 packaged software needs it to be, and we’re blind to it because we’ve all been formatted by traditional rpm syntax, but preamble data model is a long term issue for another day).

With strict consistent packaging guidelines, that we have today in Fedora today, thanks to years of FPC toil, the sub-package is well defined and the SRPM is the upstream-named thing that inherits from one of the Fedora-mandated sub-packages when upstream follows good practices. And something else entirely in the common weirdo upstream case. In an ideal world you’d just point %source_name to the sub-package you want the SRPM to inherit from, and just add a %new_package block if none of those match upstream naming, when upstream is non-standard.

Upstreams are becoming more regular, BTW, because dev-level domain-specific packaging tools (npm, go modules, rust crates, etc) need the regularity just as much as rpm. Devs are a lot less susceptible to ignore dev tool needs than system tool needs. It’s not a C/C++/automake world anymore.

Increased upstream regularity makes it possible to write macros such as the Go and fonts macros, and also makes the case where upstream is non regular and needs hand-crafted SRPM headers not inherited from a regular sub-package less common.

BTW %name might be a better name than %new_package, to stay consistent with %description for example, but I’m pretty sure that would collide with the existing base somewhere.

%name would not be better, because it says little about the purpose. What about:

%setup_package
%init_package
%package_header
%package_preamble

Well it’s not a full header or preamble, it’s just the Name: / %package line, and for many good or bad reasons, the SRPM part of the preamble starts/inits at preamble start, not at the Name: line (did I already state the whole thing is badly in need of restructuring rpm-side? I did).

%new_package had the benefit of clear intuitive continuity with %package, and it does exactly what it says, start a new package block within the preamble (modulo the Name: weirdness already stated). Existing packager habits demand to choose something name or package related, to transition gracefully from Name:/%package.

But, naming is hard and I suck at it as much as anyone else. When all is said I just need the primitive to exist at the distribution level to help the different macro sets I maintain play well with one another, and make them simpler and more reliable. I will adapt them to the naming redhat-rpm-config maintainers choose.

Regardless of the final decision it will need backporting to F31 and F32 to make the specs that use it work on stable Fedora releases without modification. As it does not depend on anything except basic rpm primitives unchanged since untold ages, that should not be a problem.

Its been more than 2 weeks now, I can't convert existing font packages to new fonts packaging guidelines or rebuild converted font packages.

I was already having a plan to file a F33 Change to convert existing packages to follow new guidelines as I think I now understood them how to use new macros.

I can provide one scratch build (https://koji.fedoraproject.org/koji/taskinfo?taskID=44401487) attempt that shows %new_package macro undefined via usage of %fontpkg

I am still not sure where exactly is the problem, is it in %fontpkg only problem then?

@pnemade this specific case, yes. Maintainer of package providing %fontpkgmacros did not wait and started to use it, so this is bug in there.

I've expressed my opinion in the earlier comments. Other than that, I've abstained myself from this case as it's gotten too personal level toxic.

Yes let’s continue blaming the only person that did coding work to workaround the rpm regression, instead of Pilatic "packagers will cope fine" statements that would have required individual packagers to rewrite manually each of the 1500+ affected specs.

And, so fun to see the people that proposed a “resolution” to avoid fixing the problem they introduced in their own project, NAKing their own “resolution” once it is coded by others in another project.

Anyway if people can’t be bothered to merge the work I should not have to do in the first place, the fonts and go macros will just go unmaintained, and people can have fun dealing with the affected packages and packagers themselves.

Thank you all for sharing your views. I have taken this issue further to FPC only for now -> https://pagure.io/packaging-committee/issue/982

1 new commit added

  • new_package: create basic SRPM header as fallback
2 years ago

rebased onto 764e774e756612b529eca2c49e3c7f74fc56bdf1

2 years ago

4 new commits added

  • update redhat-rpm-config.spec for %new_package
  • newpackage: make subpackages work when %{source_name} and Name: disagree
  • new_package: create basic SRPM header as fallback
  • Add %new_package
2 years ago

rebased onto 3c72d694792a74c8f7576efbc6633e160854f414

2 years ago

3 new commits added

  • new_package: make subpackages work when %{source_name} and Name: disagree
  • new_package: create basic SRPM header as fallback
  • Add %new_package
2 years ago

rebased onto e416a7b

2 years ago

FPC discussed this on Thursday and I'm going to go ahead and merge it. I know we could bikeshed for weeks about things like naming, but in the end this doesn't do anything but add some lua functions and a macro; it has a low potential to break anything that doesn't explicitly use it. If there are problems caused by this, or valid, serious objections arise, then we can always revisit the issue. At some point we have to try and move things forward even if, occasionally, we stumble.

Pull-Request has been merged by tibbs

2 years ago