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@xxxxxxxxx> 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.12
Yes. 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/73.patch
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,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
