Re: packaging: prefer git archives to upstream archives for Source

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

 



On Mon, Mar 31, 2025 at 9:31 PM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Mon, Mar 31, 2025 at 01:24:06PM +0200, Alexander Sosedkin wrote:
> > On Mon, Mar 31, 2025 at 12:56 PM Zbigniew Jędrzejewski-Szmek
> > Just one question: how would you make those git forges output stable archives?
> > GitHub itself explicitly says they won't and you shouldn't do that [2].
>
> Heh, I followed the link you provided, and they explicitly say:
>
> > If you rely on stable archives only for reproducibility (ensuring
> > you always get identical files inside your archive), then we
> > recommend you download source archives using the source archives
> > REST API with a commit ID for the :ref parameter. There is no need
> > to record the hash, since the commit ID ensures you’ll always get
> > the same file contents inside the archive.
>
> and also
>
> > if we intend to change either archive format, we’ll provide six
> > months’ notice in documentation, and on the blog and changelog.
>
> In other words, they understand that people expect the outputs to be
> stable, they are stable, and if they ever want to change something,
> we'll have plenty of advance notification.

That's one very optimistic reading of it.
I read it as "we broke it once, and you know what, we'll totally do it again".
We don't wanna update the entirety of fedora lockfiles once they do.

> The answer you provided answers your question.
>
> > In line with your quest to reinvent NixOS, you might be interested in
> > how it's solved there:
> > fetchFromGitHub and friends unpack the tarball first.
>
> If fetchFromGitHub is called, then it fetches from github, no?

Yes, there's an entire family of functions optimized for different forges.

> More or less what I was suggesting… And I really don't care about
> the unpacking, that is an implementation detail.

That's a design decision
that sidesteps the entire tarball reproducibility concern
while still achieving what you were after: fetching what's in SCM.

> (FWIW, I checked this myself for systemd a few months ago. I downloaded
> all the archives for all the releases of systemd from github, and then
> produced the same archives using 'git archive' locally with the appropriate
> options. The hashes were the same.)

Repeat the experiment with git from 2022, then from 2030. They won't.

> > [2] https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes

-- 
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue




[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