[Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
nim-nim
notifications at github.com
Wed Apr 8 12:16:34 UTC 2020
> Please stop spreading FUD about thousands of specs breaking. They're building just fine, here's an
> example scratch-build: https://koji.fedoraproject.org/koji/taskinfo?taskID=43124256
The *documented* *official* packaging pattern this change broke is used by at least fonts and go Fedora packages
```console
$ dnf --disablerepo='*' --enablerepo=koji-builds repoquery --whatprovides 'golang(*)' -s -q | uniq | wc -l
1240
$ dnf --disablerepo='*' --enablerepo=koji-builds repoquery --whatrequires fonts-filesystem -s -q | uniq | wc -l
331
$ date --rfc-3339=seconds
2020-04-08 13:58:38+02:00
```
So that’s 1571 sources packages in the F33 koji build repo as of now.
All of those use either the sil-mondulkiri-fonts or sil-mondulkiri-extras-fonts documented and official declaration ordering pattern. Therefore, the change makes them all potential build failures, as soon as the packager needs to use %{name} in sources, patches, or sourcedir.
Now so far I’ve been assuming good faith, that you wanted to clean up things and make them better (for everyone, not just for you as an rpm dev). Therefore, I’ve asked you to define what good common solution you wanted applied tor those patterns, so those 1571 packages can be refactored before the breakage is triggered. And I’ve proposed to take upon myself, to document the new pattern, go get it approved by FPC, to fill the Fedora change pages to get those packages changed, to get blamed by packagers for gratuitous packaging guideline changes, etc (ie, months of thankless tedious uninteresting work).
The documentable and actionable spec fixing options (as in, when you fix the spec files, not when you break them in mass waiting for others to fix the mess) are:
1. revert the change, keep things working as they were
2. evaluate Sources/Patches on non-internal use (at the point the srpm is created)
3. evaluate Sources/Patches at %prep (make it an explicit expansion barrier)
4. keep the new ”“evaluate on declaration” thing (though the more this goes on, the more you are convincing me it is ill-though and dangerous), and *as* *a* *consequence* fix the unbounded description misbehaviour that required, moving Sources/Patches before the rest of the rpm headers for automation to work;
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610923847
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200408/8afa9e7e/attachment.html>
More information about the Rpm-maint
mailing list