On Fri, May 08, 2020 at 10:23:45PM +0200, Fabio Valentini wrote:
On Fri, May 8, 2020 at 9:55 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote:
WHAT I WANT TO BE ABLE TO DO:
- View Fedora's dist-git repos as authoritative for packages built for Fedora. That is, I want to see a package on my Fedora system and be able to visit its dist-git repo to see how it's packaged.
Well said.
Make the lookaside cache optional. For SourceX lines, I want to be able to specify a git URL to a specific tag. fedpkg should use git archive to include that in the SRPM. e.g.:
Source0: https://github.com/rpminspect/rpminspect/archive/v0.12Yes. This is somewhat orthogonal to the dist-git / source-git question. It would be absolutely great to have this right now on top of dist-git, so we don't need to do the step of 'amend Source0, spectool -g, fedpkg new-sources, git commit'.
Huh? You mean have koji download sources from upstream directly? I don't think that's a good idea, and it doesn't have external network access anyway ...
And why do you need to amend Source0? I need never touch this Source0 tag since it's always pointing to the version I need: https://src.fedoraproject.org/rpms/granite/blob/master/f/granite.spec#_12
Yes, I know. I guess what I was more interested in is eliminating the need for me to download the package and do 'fedpkg new-sources'.
Koji doesn't need to download, that can be done client side as you submit the build.
If we offer the above, honor signed git tags for verification at build time.
Make PatchX lines optional. In dist-git, I should be able to set a remote pointing to the upstream repo. Then do the Fedora work on the appropriate Fedora branch. SourceX should still become a tarball using git archive and the tag. Patches should be automatically generated for SRPM construction using git format-patch or something comparing the Fedora dist-git branch with the remote branch.
Hmm, but if we specify a git ref as source, why bother with patches at all? The step of generation and application of patches is error-prone, and if have a git ref, we have the tree object linked to it, and we should unpack that as the source dir without any further ado.
You know that you can specify patches remotely as well, right? It works with github URLs and with pagure URLs (I haven't tested gitlab yet):
pagure commit - Patch0: https://src.fedoraproject.org/rpms/granite/c/5f706c7.patch pagure PR - Patch0: https://src.fedoraproject.org/rpms/jackson-bom/pull-request/6.patch github commit - Patch0: https://github.com/elementary/granite/commit/2fe8b69.patch github PR - Patch0: https://patch-diff.githubusercontent.com/raw/fedora-java/javapackages/pull/7...
It's probably not a good idea to point .spec files to PR diffs since they can change over time, but remote commits work just fine ... spectool -g fetches them just like it fetches sources.
Yes, I know I can do this as well, but I don't want to. I just want to do the work directly in a git repo. At build time I want the tools to construct an SRPM that contains whatever patches I've overlaid on the repo and the necessary commands to apply them to the source--that it also fetches and adds to the spec file. We can improve the package maintainer process while also still outputting complete SRPM files.
Thanks,