Bug 1945455
| Summary: | macros.forge expands git timestamps twice | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Michel Lind <michel> |
| Component: | redhat-rpm-config | Assignee: | Michal Domonkos <mdomonko> |
| Status: | CLOSED WONTFIX | QA Contact: | Tomáš Bajer <tbajer> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | CentOS Stream | CC: | bstinson, carl, fweimer, jwboyer, mdomonko, tbajer |
| Target Milestone: | beta | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-05 16:54:22 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1774139 | ||
| Bug Blocks: | |||
|
Description
Michel Lind
2021-04-01 00:48:50 UTC
Also note that the %date macro is not honored, and %forgemeta just uses the current date. The reason the timestamp gets duplicated in %{dist} is that rpmbuild actually parses the spec file *twice* (reason: implementation details, not important here) which the %forgemeta macro (defined in /usr/lib/rpm/macros.d/macros.forge) doesn't account for. Since it prepends the timestamp to the existing %{dist} value, when it's called the second time during rpmbuild, it reuses the previous value with the timestamp already in it, hence duplicating it.
Fixing this in %forgemeta would be quite difficult (if not impossible) without running the risk of breaking existing specs out there. The original %{dist} value ("el8" in this case) has to be retained as a suffix so we have to read it first. The thing is, we can't tell whether the timestamp was already prepended or not due to a previous call of this macro (technically, we can, of course, but that would be a dirty solution). Upstream, this macro was recently completely revamped and it no longer seems to cause this issue, but we don't want to rebase the macro in RHEL-8 as that, as mentioned, could cause regressions.
Luckily, as it turns out, this can be very easily worked around; just move the %forgemeta call to *after* the %{dist} macro usage, i.e. after the Release: tag in the spec file. The exact mechanics of why this works are unknown to me - perhaps it's because the Release: tag is only applied during the first spec pass. I've also seen other package specs utilizing %forgemeta do the exact same thing. In fact, I've tried this with the gnome-shell-extension-argos-3-5 version of the spec file mentioned in Comment 0 and it fixed the problem.
As for the date discrepancy mentioned in Comment 1, that's actually completely unrelated to this. In fact, it doesn't even work in RHEL-8 at the moment - the %date macro isn't read in %forgemeta at all. Instead, the tarball's mtime is used. Support for %date was only added later and the patch isn't in RHEL-8. While adding it into RHEL-8 wouldn't be too hard, unless it's going to be generally useful, we'd rather not backport random features.
Therefore, I'm closing this bug as WONTFIX. If you'd like to see the %date feature backported, please reopen this BZ or file a new one. Thanks!
|