On Fri, May 08, 2020 at 07:54:11PM +0000, Zbigniew Jędrzejewski-Szmek 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'.
I think it's related to the concept of integration with upstream. My desire
here to is skip the parts of fetching a release archive, putting it in the
lookaside cache, and updating the Source0 line.
* 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.
My thinking here is a project that exists in git upstream and we package in
Fedora but with a few patches of our own. You specify a remote in dist-git
for the package, fetch that, and then merge it on to the Fedora branch in the
dist-git repo. Rather than storing patch files there, you just make the edits
and commit them. The Source0 line would specify a git tag URL and part of the
SRPM process would be to do something like 'git format-patch' against the
remote to get the changes we've made locally. This is only necessary to
construct an SRPM file, but it's kind of nice and could be automated. Working
on the package wouldn't have you dealing with patches like we currently do,
you just commit changes in the dist-git repo which ends up being on the
project.
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.
s/fedpkg/anything-else/
This would be non-trivial, but I would like to have an integration that makes
it easier for package maintainers to submit PRs to their upstream repos.
Maybe it's not possible.
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".
Right. Still track Fedora-specifics in git but eliminate information we can
get programatically or from other sources.
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
