On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann <kra...@redhat.com> wrote:
> Hi, > > > It's easier on implementation. That's the main reason. I generally > > believe that > > what's easier on implementation is better. > > It's maybe easier on the copr side, but not for the copr users ... > > If you can modify the upstream project (either because you are > upstream, or in case upstream is willing to accept patches for copr > support) you can just use tito and be done with it. > > If you can't modify upstream it starts to become difficult ... > > So, what would be really helpful, especially for CI with the option to > build and test every upstream commit, would be support for *two* git > repos. One git repo where the spec-file and other build-related stuff > lives (distgit like). One git repo where the unmodified upstream > source lives. Updates on either repo triggers a build. The build runs > "git archive" on the upstream repo to generate the tarball and tweaks > the specfile (Source and Release tags probably) before kicking off mock > for the actual build. > I was additionally thinking about this and how to link the repos together. I came to the conclusion that it would be nice to be able to put something like this into .spec file: Source: https://github.com/clime/example2.git#HEAD:subpkg That is a specific (git repo url, treeish) pair that would be git archived by rpm itself or just an rpm pre-processor (placed in a packaging tool like rpkg). There already is such an option to link upstream sources: https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Hosting_Services but it's not exactly the same and this could be convenient. Wild thought here would be that the (git repo url, treeish) pair placed in Source actually does not need to be git archived. Instead, it could be built into an srpm (that would probably require additional syntax on the pair as a function application to explicitly define type of the srpm build, e.g.: Source: make_srpm(https://github.com/clime/example2.git#HEAD:subpkg) In the end, the (transitively) acquired set of srpms would be collected and built as batch build in COPR (with results possibly placed into the same build directory). I am not sure if there is any use-case for such a thing (probably not) but it reminded me of what modularity is doing (or was initially doing). > > cheers, > Gerd > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
