You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Coming from this [1] discussion, I think it would be nice if .spec file could store checksum of sources used to build the package.
Currently, using-dist git, the hashes are stored in separate "sources" file. But there is no reason, why these checksums should not be stored directly in RPM. That would allow the tooling to actually download the sources from URL specified by SourceX tag and verify, that the file has the expected content (and get rid of "sources" file, which RPM does not know nothing about).
I can imagine downloading sources were not good idea when RPM came to live, but it would make things such as submitting rebase PRs, commiting just .spec file without need of uploading sources, etc easier these days.
There are several ways to do that I can think of, but not sure how feasible they are:
Please note that the proposed format of the line is the same as the format of the line in current dist-git sources file.
Use "Provides" to simulate something like this? That would probably need least effort (or no effort on RPM side), but I can't see how this could become standard for all RPM based distros:
Coming from this [1] discussion, I think it would be nice if .spec file could store checksum of sources used to build the package.
Currently, using-dist git, the hashes are stored in separate "sources" file. But there is no reason, why these checksums should not be stored directly in RPM. That would allow the tooling to actually download the sources from URL specified by SourceX tag and verify, that the file has the expected content (and get rid of "sources" file, which RPM does not know nothing about).
I can imagine downloading sources were not good idea when RPM came to live, but it would make things such as submitting rebase PRs, commiting just .spec file without need of uploading sources, etc easier these days.
There are several ways to do that I can think of, but not sure how feasible they are:
But new tag probably means issues with backward compatibility.
Please note that the proposed format of the line is the same as the format of the line in current dist-git sources file.
The text was updated successfully, but these errors were encountered: