[Rpm-maint] [rpm-software-management/rpm] A specfile parser without Turing-Complete side-effects (Discussion #3906)

[Pavel Raiskup]

@fweimer-rh wrote
> But treating dist-git as the source of truth is a choice. We would we make this choice?

We did this decision back then, and I don't ask anyone to change it.  The cat is out of the bag.

> Contrast this with the dist-git service, which can simply return different Git repository contents at different times (with some effort, even for the same commit hash).

Do you mean that maintainers may start generating a Git hash collisions on purpose?

> But that source RPM is then used in a disconnected environment to build another source RPM, which is then used to build the actual binary packages. So the source RPM still contains evidence of what is going.

The contents of source RPM ship modified sources, so we could notice - yes.  But how do we detect that this is happening?

> About 5% of Fedora packages use macros in Version:.

Normal text expansion macros in Epoch/Version are just OK!  It's OK to continue using `%{lua:` and `%()` things!
The only problem is when `%{lua:` and `%()` things are used in Epoch/Version (and only there!), because we have to let rpmautospec to process it, and even the historical variants.

> I really don't want to see this as a default because it just pushes actual distribution development

I don't see how.  Can you elaborate?
Again, the new mode that I asked for wouldn't be used **anywhere, but** in situations when we can't afford any surprises.
E.g. in `fepdkg verrel` or when a build system prepares sources for (isolated) Mock build.  And because `fedpkg verrel` shouldn't suddenly start lying (when we implement the security measuer), we need to fix [a few packages out there](https://github.com/praiskup/norpm/blob/main/rawhide-tests/expected.yaml) and that's why we need the policy.

@kanru
> The version is extracted from the changelog file and it's the only place a complete version exists.

I'm not a Debian expert, but this doesn't seem that bad.  It's completely safe to read git commit messages, and a historical variant of some text files.  It's **not OK** to have TC side-effects when doing so.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3906#discussioncomment-14350520
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/3906/comments/14350520 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20250909/4621538e/attachment.htm>