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 > > * 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. Fabio > > Multiple remotes should be possible should new and > > old versions of the upstream project need to be supported. Fedora dist-git > > branches should know their remote. > > > > * I still want to be able to do 'fedpkg srpm' and get a standalone > > ready-to-build SRPM file that I can carry around. > > > > * Possibly extend fedpkg to helper package maintainers submit patches from the > > package to the upstream project. > > Is 'fedpkg' the best place for this? Submitting PRs from a git branch > is a very generic thing, and there's plenty of tools to do that already. > And those tools might even be forge-specific. E.g. github has hub and now > an official gh tool, and it's unlikely that fedpkg will ever do github PRs > as well as gh. And when fedora patches are just a branch, then the generic > tool can be used. > > > PRs in dist-git would be more meaningful to me if we were able to have the > > upstream repo as a remote in dist-git and our branches just an extension of > > that. > > Me likes. This would solve the perennial problem of "should I abuse > proven-pakcager privs to do 'fedpkg new-sources' before submitting a > PR?", which has two bad answers: "yes, and annoy the maintainer by > polluting the cache if the PR is rejected", and "no, and have all CI > fail". > > Zbyszek > _______________________________________________ > 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 _______________________________________________ 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
