[Rpm-maint] [rpm-software-management/rpm] RFE: read sources checksums from the SPEC file and verify them (#463)

[Michal Novotný]

> For me, causal user of OS sometimes building small packages, current way of building rpms is very confusing. There are various tools which duplicate functionality: rpmbuild, mock, rpkg, fedpkg etc. It's much harder to understand than PKGBUILDs on Arch Linux for example. For me having ability to declare checksums in rpmspec in standardized way would make UX much better.

I am not sure what it would actually bring. It is good that you can make `%_disable_source_fetch 0` trustworthy but one could also do e.g.

```
Source0: https://github.com/release-engineering/dist-git/archive/dist-git-1.12-1.tar.gz#sha256
```

with the current rpm syntax and then have a macro that verifies the tarball checksum based on the `#sha256`. Is it too hacky? :)

It might not even be a hack because https://tools.ietf.org/html/rfc2396#section-4.1 - the fragment identifier is in the realm of client.

So imho, new rpm syntax is not even needed.

I think we could extend rpm macros to support this and it would be nice e.g. for COPR.

It's a pity that url fragment already seems to be used for something: https://fedoraproject.org/wiki/Packaging:SourceURL#Troublesome_URLs

but that maybe it doesn't necessarily mean we couldn't extend its use...? Btw. there is a note: 

"Sometimes this does not work because the upstream cgi tries to parse the fragment "

that would be a server-side error according to the RFC.

But for Fedora this has still a limited use because we would like to be independent of any of github/gitlab/bitbucket stuff.

We could use that information (the hash) to automatically fetch the sources from upstream the first time when they are not yet present in our (Fedora) lookaside cache and then further rely on the `sources` file, the checksum there and the lookaside cache but I think this is a problematic solution. It would mean build system would need to commit into dist-git, which would mess up automatic versioning (if there is any). I haven't thought about this too much, there might be other issues.

I think the fedpkg upload way is quite fine and it can be automated too (outside of Fedora infra) if one trusts 100% to the tarball source/provider. It's hard to tell if such automation should be recommended.

> 
> This is the reason of huge success of AUR and PKGBUILDs in Arch Linux world — simplicity.



-- 
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/463#issuecomment-601922444
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200320/5003470a/attachment.html>