#982 Font packaging stopped working in rawhide/F33
Closed: fixed 7 months ago by ignatenkobrain. Opened 7 months ago by pnemade.

Hi,

FPC approved new fonts packaging guidelines in https://pagure.io/packaging-committee/pull-request/934

Then it came into f32+ to implement. I see advantages of this policy rewrite, so I started font spec file conversion for my packages in Fedora. It worked fine. I got very good help from @nim for this conversion work. Some of my packages are already converted which are going to be soon FTBFS when F33 mass-rebuild will happen because of this packaging policy coding become incompatible with new rpm-4.15.90 version. On F32 system with rpm-4.15.1, new fonts packaging working fine.

I think this incompatibility has been discussed in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83 but could not be concluded to some working fix by either side of discussion.

I am approaching FPC to guide me further. I do not like font packages in F33+ to be like some converted to use FPC mandated new fonts packaging guidelines and some still using old packaging.

Do FPC have some policy on such issues? What to do if policy once approved is not getting implemented in Fedora or policy suddenly becomes not working and there is no fix available.

I request FPC members to share their view on this issue. If they think some packages using new guidelines and some old is fine then please say so here.


So strictly speaking, this is bug in fonts-rpm-macros since https://pagure.io/fonts-rpm-macros/c/3e10c3a946507dbff047b4806470fb06a09aa3dc?branch=master commit which uses something which is not defined anywhere and even pushing then this update to Fedora to intentionally break packages before redhat-rpm-config maintainers were able to provide feedback on the new approach being proposed (https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#comment-42674).

I guess the fix would be to revert fonts-rpm-macros to 2.x to restore previous behavior.

I'm really not happy how these things are going on, so at some point I might propose to revert packaging to the pre-F32 and just wait until @nim and RPM maintainers will come to common point. As a bonus point, make it go through Change Process.

That means reverting font packages to pre-2007 state and the Go packages to pre-2017 state.

That’s how long Fedora macros have been using the coding patterns rpm casually broke.

Not to mention, none of those would work with the current state of the distro (both as deps and provides).

And, frankly, there’s been zero constructive comment from you in all those exchanges, and proposing to wipe out years of other Fedora contributions so you don’t have to think about the whole thing and read the actual PR that was coded on rpm maintainer suggestions to adapt things to the new rpm world order is yet another provocation.

Hopefully this ticket gets discussed in upcoming meeting of FPC. If it fails I may need to move forward to FESCo. We can't use Fedora with broken packaging macros.

Can we please revert Rawhide to fonts-rpm-macros version 2?

@petersen Sure you can revert all the work that went into fixing the macros to adapt to the unannounced rpm 4.15 parser changes .

If you do that you get to maintain the result. I won’t invest more time in maintenance just so my work gets reverted because others do not want to do their part. Which is just deciding on a macro name and merging. How hard is that?

Of course if there are problems in the code proposed for merge in redhat-rpm-config, I will look at them, but none of the armchair mudsliders actually looked at the code seriously enough to point at those.

Practically, I’m completely fed up with the toxic attitude of people that:

  • can not bother analysing the problems Fedora contributors hit once they occur,
  • can not bother looking for practical implementable solutions,
  • can not bother implementing those solutions,
  • can not bother reviewing the implementations others did,
  • and then try to cover up their own deficiencies by attacking the implementer and its implementation (that they still did not bother reading seriously)¹

I had to push things in devel just to force people to look at the problem. That worked briefly, now they want to revert to doing nothing before the fix resulting from the look up is merged and we can move to other things. How sick is that?

If FPC also wants to cover up things by pretending nothing happened and removing contributor work to make the situation go away I won’t be there to rebuild once again.

¹ I looked at enough redhat-rpm-config and rpm macro code to know my code level is as good as the average “official” macro, a lot better than a lot of them, and miles ahead on the documentation front. Documentation that was not merged because the naysayers did not know what to do with documentation once it was provided on a platter, so used they were to their own undocumented tinkering.

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

7 months ago

As two members here suggested to use 2.x.x version, I picked the last build from this version 2 series -> https://koji.fedoraproject.org/koji/buildinfo?buildID=1488859

I added Epoch:1 and built new package https://copr.fedorainfracloud.org/coprs/pnemade/fontstest/build/1390978/

Initially I built few packages easily because I had srpms available on my system but then I tried to build srpm on my system for already converted fonts packages in rawhide against fonts-rpm-macros-2.0.5-2 copr build. For that I first installed this new package's all binary rpms on the system. Then I tried to generate srpm and submit to copr repo but local srpm build failed.

rpm is giving me Unknown tag: %fontmeta on some packages where spec have %fontmeta macro used and not generating srpm thus no submission to copr build.

if anyone want to try this failure then install fonts-rpm-macros-2.0.5-2 copr build and take dejavu-fonts to rebuild locally on your system. You will get Unknown tag: %fontmeta.

So, maybe this helps:

relevant dejavu-fonts package history, chronologically:

  • dejavu-fonts continues to build fine in koschei up until 2020-04-24
  • dejavu-fonts starts to fail to build in koschei with fonts-rpm-macros 3.0.3

Summary

dejavu-fonts built fine, even with a patch, until fonts-rpm-macros was
was updated to 3.0.3 (which, as I understand, should address the Patch problem,
but which was never a problem in the first place here?)

We talked about this ticket at today's meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-05-21/fpc.2020-05-21-16.00.txt):

  • #982 Font packaging stopped working in rawhide/F33 (geppetto,
    16:16:39)
  • ACTION: nim to provide SRPM that worked before and does not work
    with new RPM. (geppetto, 16:48:13)
  • ACTION: nim to revert usage of %new_package because that is breaking
    fonts packages for future patch breakage (geppetto, 16:48:48)
  • ACTION: FPC will review provided SRPM and figure out how to proceed
    from there, pushing back on rpm maintainers etc. if needed
    (geppetto, 16:49:18)
  • ACTION: ignatenkobrain to clean up the tickets around this and keep
    just one place for discussion (ignatenkobrain, 16:57:47)

Thank you very much FPC people who participated in yesterday's meeting and Nicolas also.

Let's hope to get some fix soon in Fedora for this issue.

Fonts (for ~ 13 years) and Go (for ~ 4 years) use automated package header generation.

That means they generate complete HEADER blocks in the preamble, that use indifferently Name: or %package

Name: or %package -n
Summary:
… 
%description -n

There is no special-cased SRPM logic, naming the SRPM after the first generated package or not is a functional packager decision not a technical one, Fonts and Go spec files use both styles depending on upstream state.

From the start up this had to cope with rpm parser constrains. One of those constrains is that the parser is unable to close a %description in the preamble without starting a new block.

Therefore it is not possible to do the natural

macro declaration & processing for first HEADER

HEADER

macro declaration & processing for second HEADER

HEADER

macro declaration & processing for third HEADER

HEADER

Someone (probably one of the rpm maintainers) suggested early on to move all the parts that did HEADER-independant processing before the headers list to workaround this constrain.

macro declaration & processing for all HEADERS


HEADERS

Practically that meant

macro declaration & processing for all HEADERS

Sources and Patches

HEADERS

Source and patch filenames consume part of the processing and they can not be injected between HEADER blocks because of the aforementionned %description limitation. A packager can not easily inject lines in the middle of a generated HEADER block and every spec needs sources so source declaration better be easy.

This is a key design decision. It was possible because the rpm parser was lenient and evaluated declarations in enough places declaration ordering did not matter.

That changed in rpm 4.15, rpm stoped being lenient. That manifests when building
https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403021/
https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403020/

Copr succeeds building those so their basic structure is good, however, if you try to rebuild the second on a system where %sourcedir is set to a package-specific root in ~/.rpmmacros

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

I will now fail with

$ rpmbuild -bs ~/rpmbuild/SPECS/sil-mondulkiri-extra-fonts.spec 
warning: undefined macro(s) in %{_sourcedir}: ~/rpmbuild/SOURCES/%{name}
error: Bad source: ~/rpmbuild/SOURCES/%{name}/Mondulkiri-5.300.zip: No such file or directory

Which shows the rpm parser no longer copes reliably with such spec files.

This is hardly an exotic %_sourcedir construct. I’ve been using it continuously for 20+ years, and other Fedora packagers do too:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FE4V5MN667F24WA4AB34EETBWNFQGTFS/

Ironically you can check that the fully-automated package, sil-mondulkiri-fonts still works fine, it’s the one with traditional manual Name: declaration, sil-mondulkiri-extra-fonts, that breaks. Both sil-mondulkiri-fonts and sil-mondulkiri-extra-fonts rpmspec -P to the same basic spec structure, because things are complex enough without supporting multiple Font and Go spec codeflows.

All this has been identified quite early
https://bugzilla.redhat.com/show_bug.cgi?id=1820349#c6 (2020-04-03)

… except, without any productive resolution, because rpm maintainers made clear they had no intention of helping make those spec safe with the new rpm parser behavior.

It took quite a lot of heated exchanges, before @pmatilai recommended wrapping fully SRPM name processing, to make all affected packages behave like sil-mondulkiri-fonts:

Or if you want to use a macro for the project name then declare and use a macro for that, which is free of any rpm spec implied ordering. Which is basically what all these fontpackages do already for many, many things
https://pagure.io/packaging-committee/issue/968#comment-641830

That is what would become %new_package in
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83

And @pmatilai felt strongly enough about it he added a similar variable indirection in the rpm spec file itself
https://src.fedoraproject.org/rpms/rpm/c/1b2c14f39a1c342d3e3ebde5f783bc974737e76a

(there would not be much point to define a macro for the srpm name without making sure it was used when package names are declared in Name:/%package, and I did not automate 1500+ Fedora packages to start declaring macros manually spec file by spec file)

However, %new_package alone would not work without heavy macro restructuring and packager discipline. I can do the macro restructuring (lots of work I could have done without, but I’d rather have solid macros that something rpm maintainers tell me is unsupported). Packager discipline is harder. I should know, I authored enough packaging guidelines.

Fortunately @ffesti provided the other half of the solution (thank you @ffesti, that was the trickiest part):

@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.
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#comment-42746

Switching the Go and Font templates and macros to use %sourcelist and %patchlist ensures that the packager can use all the preamble macros safely in his sources and patches.

Thus:

  • %new_package makes sure macro sets play nice with one another without relying on %{name}

    • rpm maintainers object to %{name} use before the Name: line
    • there is no Name: line to move when the SRPM block is generated, just a complete block
    • the SRPM block can not be moved as a whole because %description can not be closed without starting a new block, so you can not put processing between HEADER blocks
  • changing the Fonts and Go packaging templates to use %sourcelist and %patchlist makes sure human packagers need not worry about all this. By the time the %sourcelist and %patchlist sections start in the spec file all of the above has been safely defined

To make this all end gracefully:

  • %new_package needs to be reviewed, merged and backported
    • backported because otherwise we need to deal with different packaging guidelines in different releases
    • this is possible because rpm devs refused to change anything their side, so %new_package will work the same in all stable releases

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.
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#comment-42261

  • Fonts and Go macros need to be updated to use %new_package

    • I have a working Font implementation, that builds all my test package set. It will probably need more polishing but it’s mostly done.
    • Go is another can of worms, I’ve started working on it but I won’t commit fully to it before the approach is proven to work fonts-side (that blocks all the automation work I started to support Go modules in Fedora)
  • Fonts and Go packaging templates need to be updated to use the result

    • this is mostly using %sourcelist and %patchlist
    • with few changes on the rest of the packaging except some macro naming changes that result from using a common %new_package core that forces making fully consistent names that were only approximatively so
    • the font part of the documentation in 90% done, waiting on the final implementation for the finishing touches and submission to FPC

https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403021/

So I have tried to check this, but was not able to build it due to:

error: line 37: Unknown tag: %new_package -n %{currentfontpkgname}

Please fix this first so that we can deep dive into the issue.

As requested by FPC, this is an example before any of the devel changes. The copr is a vanilla F32 buildroot with no changes expect the two test builds.

You need to build it on a F32 system or downgrade your system to fonts-srpm-macros 2.x (the one that existed in Fedora before the work-arrounding began)

Except for the fact that the sil-mondulkiri packages are simpler and cleaner than dejavu, and permit testing both automated SRPM headers and non automates SRPM headers, all the rest is identical to the initial report in https://bugzilla.redhat.com/show_bug.cgi?id=1820349

Aside from all the font packages in devel which have been waiting for %new_package to be reviewed and merged to build for almost a month now,

https://src.fedoraproject.org/rpms/dejavu-fonts/c/e91ddfba9c9fc82b8f8e5a83a3db771354ebf91d

I've started on a new series that fully exploits @ffesti’s proposal to use %sourcelist. The package state in devel is an implementation of the first half of the solution, because at that time @ffesti had not made his suggestion.

https://copr.fedorainfracloud.org/coprs/nim/sourcelist-and-new_package/builds/

I'm not proposing it for inclusion yet because it requires more redhat-rpm-config changes than just %new_package, but it can give FPC an early idea of where this is all going. The second commit in
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83

is actually a backport of the changes made to %new_package in the new series, because the implementation here is more mature and better tested.

It’s a lot more ambitious than the early limited work-arounding in devel because it melds part of the coding I had already started to support Go modules (and that I had to give up on because of this issue) with taking full advantage of %new_package and %sourcelist to improve and simplify pre-existing spec structure.

So I took the same build from COPR (as mentioned in my previous comment), downgraded fonts-rpm-macros to 2.0.5-1.fc33 and tried to build it.

❯ rpmbuild --rebuild ./sil-mondulkiri-fonts-7.100-5.fc32.src.rpm 2>/dev/null | grep Wrote
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-all-7.100-5.fc33.noarch.rpm
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-doc-7.100-5.fc33.noarch.rpm
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-busra-fonts-7.100-5.fc33.noarch.rpm
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-7.100-5.fc33.noarch.rpm

Don't see any breakage with new RPM.

Did you have %sourcedir set to a package-specific root in ~/.rpmmacros

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

Or another variant such as the one José Abílio Matos mentioned on fedora-devel ?

✦ ❯ cat ~/.rpmmacros 
%_sourcedir %{_topdir}/SOURCES/%{name}

~/Downloads/tmp 
✦ ❯ rpm -D "name foo" --eval "%{_sourcedir}"
/home/brain/rpmbuild/SOURCES/foo

~/Downloads/tmp 
✦ ❯ rpmbuild --rebuild ./sil-mondulkiri-fonts-7.100-5.fc32.src.rpm 2>/dev/null | grep Wrote
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-all-7.100-5.fc33.noarch.rpm
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-doc-7.100-5.fc33.noarch.rpm
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-busra-fonts-7.100-5.fc33.noarch.rpm
Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-7.100-5.fc33.noarch.rpm

~/Downloads/tmp 

With rpm-4.15.90-0.git14971.12.fc33.x86_64.

Yes, this one works. To quote myself

Ironically you can check that the fully-automated package, sil-mondulkiri-fonts still works fine, it’s the one with traditional manual Name: declaration [sil-mondulkiri-extra-fonts] that breaks .

It took quite a lot of heated exchanges, before @pmatilai recommended wrapping fully SRPM name processing, to make all affected packages behave like sil-mondulkiri-fonts:

That is what would become %new_package in
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83

Yes, this one works. To quote myself

So we have asked you to provide a package that builds fine with RPM 4.14 and does not build with 4.15 / 4.16. I thought that COPR build you provided is supposed to demonstrate that.

Can you link the SRPM that IS broken with 4.15/4.16 but works with 4.14?

So FPC asked to provide an an example and to explain what %new_package was about, because “nobody else understands what it does” (direct FPC meeting quote).

I provided both the broken example and the one that still works, and lead to @pmatilai recommending wrapping the SRPM processing in what would become %new_package.

Could you please just read the report fully instead of skipping half of it?

https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403020/

I tried to build this one with RPM 4.15, but it fails… with irrelevant problem to this ticket:

error: line 167: Bad Requirename: qualifiers: Requires(meta):  sil-busra-dot-fonts = 5.300-6.fc33

So it definitely can't work with RPM 4.14

Yes Fedora 32 has Requires(meta) and previous releases did not

If you want to rewind rpm to rpm 4.15, you can use the F31 fonts-srpm-macros, it does not include F32 changes

@nim ok, can you please provide exact steps how to reproduce the issue: what versions of fonts-rpm-macros & co are needed for RPM 4.14 and then for RPM 4.15. What SRPM to use and what macros need to be set or not set. In a numbered list so that people can just go step-by-step and observe the issue. Ideally provide some minimal reproducer that does not involve debugging hundred lines of LUA and RPM macro to understand the issue.

Also from that COPR I see that you have:

Source0:  https://scripts.sil.org/cms/scripts/render_download.php?format=file&media_id=%{archivename}&filename=%{archivename}.zip#/%{archivename}.zip
…
Patch0: %{name}-dummy.patch
…
Name: sil-mondulkiri-extra-fonts

RPM is parsing preamble line by line, then goes to the sections like %sourcelist and such. If you use %{name} in the %{_sourcedir}, you need to have all Sources / Patches defined AFTER Name. When RPM sees source (a Source or a Patch), it tries immediately to call rpmGetPath("%{_sourcedir}/", …) that of course fails because the macro can't be fully expanded at that time.

This is a bug in the spec file combined with your configuration of %{_sourcedir} that uses %{name}. This does not break any single package in Fedora that are built in Fedora Infrastructure (Koji).

Anyhow, I've tried to reproduce the issue with some minimal spec file but can't which suggests to me that some of the macro (fontpkgnameX) are expanded too late (I guess that it expects files to be already unpacked, hence they depend on the Name and this thing just blows up).

@ignatenkobrain so now you’ve finally reproduced what was in the original ticket. @pmatilai did more and traced it to the exact rpm 4.15 commit that made things break.

And, I won’t bother arguing here who is in the right and who is in the wrong. Probably, nobody.

Remember that the Fonts and Go macros were many years in the making, way before rpm 4.15 was on the roadmap, they only landed at about the same time because it took months to write the documentation FPC reviewed, and more months for this documentation to be reviewed and approved.

Also

This is not about how things ideally would be, this is about the existing spec reality. Which is that the spec is not a declarative language but a weird piece of script that executes from top down with multitude of arbitrary side-effects all along the way.
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610211002

Given that there is no wish rpm maintainer side to revert this commit, and unless you have some magic solution rpm side to keep things working, do you still not understand and disagree with the making things work plan outlined by @pmatilai and @ffesti. Namely:

  1. @pmatilai: making sure the macro logic does not use %{name} directly, only a safe %{source_name} that does not suffer from rpm ordering constrains → that is the %new_package PR

  2. @ffesti: making sure human packagers declare sources and patches after all the preamble things that end in source and patch filenames are defined → that is switching the macros and templates to %sourcelist and %patchlist (which was not possible before rpm 4.15 since they were added in rpm 4.15)

@nim as you abstained from providing reproducer: do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec?

@ignatenkobrain I don’t think anyone understands how deep the issue is. As @pmatilai wrote himself:

Much to my surprise, this used to work in rpm < 4.15. Bisecting shows it was broken by commit 93604e2 which claims to have no functional changes, but clearly it did as spec parse now fails with "error: Bad source: %{name}-urn-dtd.patch: No such file or directory"
https://github.com/rpm-software-management/rpm/issues/1161#issue-593220447

That’s why, since no one claims to understand the extent of the damage, the two-part resolution plan proposed by @pmatilai and @ffesti is simple and brutal:

  • move all sources and patches to %sourcelist/%patchlist after the preamble to remove any chance of problematic interaction between the preamble ordering and source and patch naming
  • abstract away preamble srpm name macro processing in a variable, different from the one Name: will set, to remove any chance of problematic ordering between the Name: line and this processing (that’s %new_package)

And please stop claiming there is not reproducer or information was not provided. You reproduced it. Panu reproduced it. Your attitude is quite tiring and unfriendly.

@nim

can you please provide exact steps how to reproduce the issue: what versions of fonts-rpm-macros & co are needed for RPM 4.14 and then for RPM 4.15. What SRPM to use and what macros need to be set or not set. In a numbered list so that people can just go step-by-step and observe the issue. Ideally provide some minimal reproducer that does not involve debugging hundred lines of LUA and RPM macro to understand the issue.

You did not provide this.

Hence I am once more asking:

do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec?

@nim Please answer this simple question as yes or no. In case of no, please provide how exactly to reproduce this.

@nim I'm sorry, but I fail to follow your arguments / evidence.

What about:

  • moving Name above PatchX where possible, or
  • just not using %{name} macro in Patch file names where it's not possible to move Name above PatchX

Would doing those two things solve the problem?

@decathorpe

  • moving Name above PatchX is not possible in all cases because of the structure of those spec files. You can easily check it by comparing sil-mondulkiri-fonts and sil-mondulkiri-extra-fonts spec structure.
  • not using %{name} macro in Patch file names goes against decades of Fedora packager conditioning
  • creating special cases also adds to the human packager burden. Right now sil-mondulkiri-fonts and sil-mondulkiri-extra-fonts are almost line-by-line identical, that did not happen by chance, it was a lot of deliberate design work to reduce the complexity packager side

Frankly, it’s a lot easier to fix the implementation to be always correct, than to fix people, or convince them to be careful about weird special cases, or to have them play ordering roulette games with the rpm parser.

I do not especially like to write guidelines, you do not especially like to review them, and packagers do not especially like to read them. Better to have things that just work.

Did you take a look at the code in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#request_diff ? It is way simpler and easier to understand than all that has already been written here

  • moving Name above PatchX is not possible in all cases because of the structure of those spec files

That's why I made the case distinction in my comment.

  • not using %{name} macro in Patch file names goes against decades of Fedora packager conditioning

I only encounter Patches with such names in packages that are older than 10 years. But that's beside the point. Expanding %{name} or not using it at all would solve your problem, yes?

I only encounter Patches with such names in packages that are older than 10 years.

Panu actually counted %{name} use in Fedora Source names:

I could 13730 uses of %{name} in SourceX in Fedora as of a few days ago.
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610286641

That’s how deeply ingrained the practice is. And did not count use in Patch, which is the same as far as this issue is concerned. And no one knows if other parts of the preamble are now problematic, %{name} is just the most commonly used, and triggered the rpm issue first.

Using %sourcelist and %patchlist makes it impossible to trigger this kind of problem in Sources and Patches which is why I like @ffesti’s suggestion.

Expanding %{name} or not using it at all would solve your problem, yes?

No that would not. It would solve it in my spec files, not all the spec files that use my packaging templates and that Fedora packagers expect me to support (as I did for more than a decade now).

That’s how deeply ingrained the practice is.

Do I care about cruft? No.

Expanding %{name} or not using it at all would solve your problem, yes?

No that would not. It would solve it in my spec files, not all the spec files that use my packaging templates and that Fedora packagers expect me to support (as I did for more than a decade now).

How can it solve it in your packages but not solve it for others?

Because solving it in other spec files implies writing documentation and answering the cries for help of packagers that hit the same problem for years, while changing the macros and templates to work in all cases is a one-time operation.

Alright, I give up. If you want to add another layer to your Rube Goldberg machine instead of doing those simple - possibly even scriptable - changes, then go ahead, but you won't get any support from me ...

/signing off

do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec?

@nim please answer this question (try number 3). Just simple yes or no. In case of no - write more details.

@ignatenkobrain

can you please provide exact steps how to reproduce the issue: what versions of fonts-rpm-macros & co are needed for RPM 4.14 and then for RPM 4.15.

Just use the Fedora 31 fonts macros. Most of the code was written months before rpm 4.15 was released, I doubt they include anything 4.15 specific. If some late adjustment is 4.15 specific I will be happy to provide a backport.

do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec?

The issue occurs with the spec and configuration provided as reproducer. It may occur in other cases but I do not know of them and do not know rpm internal code well enough to guess what they would be. I did not deliberately set up to trigger rpm breakage. I hit it as part of my everyday packager and macro maintainer activity.

do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec?
The issue occurs with the spec and configuration provided as reproducer

This is exactly what I was trying to get from you through all dozen of comments here.

Sorry, but this does not qualify as "breaking 1750 packages". It simply did not break any Fedora packages that are built in Fedora Infrastructure.


@pnemade @petersen I have reverted fonts-rpm-macros to 2.0.5 in Rawhide so that you can actually build fonts.

@nim Please continue discussion in a normal way with redhat-rpm-config maintainers and once you have agreement with them about %new_package and the PR is merged - feel free to update fonts-rpm-macros to the new version. Also avoid breaking fonts or any other macros before that.

:fire_engine: is not needed here, FPC can stop worrying now.

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

7 months ago

Thank you @ignatenkobrain for helping on this ticket. I confirm packages are built successfully with this revert of fonts-rpm-macros package.

Login to comment on this ticket.

Metadata