Re: Fedora Source-git SIG report #1 (June 2021)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote:
> On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
> >
> > On 24. 06. 21 11:16, Tomas Tomecek wrote:
> > > ## Choosing git forge to host source-git repositories
> > > We need to find a home for all the source-git repositories. This is
> > > actually a really hard task because we have many options (github.com,
> > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or
> > > on-premise) and different expectations: some projects already have
> > > repos set up on different platforms while Pagure is the primary forge
> > > now. Since the CPE team is investigating GitLab as a forge, it's even
> > > harder for us to figure out the primary forge. We may end up
> > > supporting both actually: pagure.io and gitlab.com. What are your
> > > thoughts on this topic? Would you prefer pagure.io or gitlab.com
> > > More info:
> > > * https://pagure.io/fedora-source-git/sig/issue/1
> > > * https://pagure.io/fedora-source-git/sig/issue/7
> >
> > I would expect that since the soruce git is just an intermediate thing,
> > supporting "any forge" is nice to have, but hard. I'd start with some common
> > options (Pagure + 1 other) and see where you'll get.
> 
> Yep, that's exactly what I'd like us to do. As soon as we have the
> service which accepts processes events up and running, it shouldn't be
> that hard to teach it new fedora-messaging messages or webhook
> payloads.
> 
> > > ## High-level workflow proposal up for review
> > > Hunor proposed a high-level workflow linked below and I strongly
> > > recommend reading it. We have also started discussing many details in
> > > the process, such as getting archives: should we generate one from the
> > > source-git repo or use the official release archive from upstream?
> >
> > One thing to consider is that the upstream tarballs might be cryptographically
> > signed and packages should verify the signature in %prep.
> 
> This is a very good point - in such a case, we should always pull the
> official upstream tarball instead of generating a new one downstream.

Hmm, but how would that work? I thought that the whole point of
source-git is to build from a commit that contains some upstream 
version + downstream patches + downstream distro config like the spec file,
and that the build step of applying downstream patches just doesn't exist.
If you reuse the upstream tarball, then by necessity those downstream
patches need to be serialized and applied on top like in dist-git. So
you lose the property that the checkout from version control is *the*
source you build, but you also lose the property that the source you
build is what was signed (since patches are applied).

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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux