Bug 181675 - [GTK][JHBuild] Download tarballs instead of cloning git repositories
Summary: [GTK][JHBuild] Download tarballs instead of cloning git repositories
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Fujii Hironori
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-16 03:07 PST by Fujii Hironori
Modified: 2020-10-12 17:08 PDT (History)
4 users (show)

See Also:

Attachments
Patch (3.20 KB, patch)
2018-01-16 03:10 PST, Fujii Hironori 		mcatanzaro: review-
mcatanzaro: commit-queue-
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fujii Hironori 2018-01-16 03:07:21 PST 
[GTK][JHBuild] Download tarballs instead of cloning git repositories

Relevant bugs:

  Bug 170426 – [GTK][JHBuild] Fetch libvpx from a release tarball instead of git
  Bug 106552 – [EFL][jhbuild] Use tarballs for gstreamer instead of git
Comment 1 Fujii Hironori 2018-01-16 03:10:01 PST 
Created attachment 331379 [details]
Patch
Comment 2 Adrian Perez 2018-01-16 03:48:45 PST 
Comment on attachment 331379 [details]
Patch

Patch looks good to me, r+ (informally reviewing).
Comment 3 Michael Catanzaro 2018-01-16 07:14:46 PST 
Comment on attachment 331379 [details]
Patch

The problem with github.com is that GitHub sometimes changes the way its tarballs are generated. And the tarballs get generated on the fly, so then the hash will no longer match, and the JHBuild will fail. So while yes, this is desirable in theory, in practice it will fail randomly some date in the future. :(

You couldn't have known this... it's something we've learned the hard way in GNOME.
Comment 4 Carlos Alberto Lopez Perez 2018-01-16 07:30:45 PST 
(In reply to Michael Catanzaro from comment #3)
> Comment on attachment 331379 [details]
> Patch
> 
> The problem with github.com is that GitHub sometimes changes the way its
> tarballs are generated. And the tarballs get generated on the fly, so then
> the hash will no longer match, and the JHBuild will fail. So while yes, this
> is desirable in theory, in practice it will fail randomly some date in the
> future. :(
> 
> You couldn't have known this... it's something we've learned the hard way in
> GNOME.

Right.. I confirm this.
Comment 5 Adrian Perez 2018-01-16 12:22:28 PST 
(In reply to Michael Catanzaro from comment #3)
> Comment on attachment 331379 [details]
> Patch
> 
> The problem with github.com is that GitHub sometimes changes the way its
> tarballs are generated. And the tarballs get generated on the fly, so then
> the hash will no longer match, and the JHBuild will fail. So while yes, this
> is desirable in theory, in practice it will fail randomly some date in the
> future. :(
> 
> You couldn't have known this... it's something we've learned the hard way in
> GNOME.

Ouch, that bites! It would then be desirable to mark a tag in GitHub
as a “release” _and_ upload source tarballs for that release. Those
are to be created by the developers and GitHub will _not_ change them,
ever. See:

  https://help.github.com/articles/creating-releases/

After that's done, we could land an updated version of this patch which
links to the files attached to the release (instead of linking to the
tarballs which GitHub creates on-the-fly from Git tags).
Comment 6 Fujii Hironori 2020-10-12 17:08:39 PDT 
Flatpak SDK is used nowadays. Closed.