Skip to content

Conversation

@bgilbert
Copy link
Collaborator

wrapdb.mesonbuild.com abstracts over the GitHub URLs for wrap files and patch zips, but not for mirrored sources: create_release.py generates source_fallback_urls which point directly to the wrap's GitHub release. As a result, GitHub isn't just an implementation detail: we can't retroactively add additional mirrors, and the existing mirror will break if we ever have to move off GitHub. Add a get_source endpoint similar to get_patch so create_release.py can start using it.

While we're here, disallow trailing garbage in v2 URLs to improve hygiene. (I'm not aware of anything currently sending trailing garbage, but if such code exists this will obviously break it.)

cc @tp-m

We currently ignore any trailing garbage after a matched URL.  Return 404
instead to improve hygiene.

I'm not aware of anything currently sending trailing garbage, but if such
code exists this will obviously break it.
wrapdb.mesonbuild.com abstracts over the GitHub URLs for wrap files and
patch zips, but not for mirrored sources: create_release.py generates
source_fallback_urls which point directly to the wrap's GitHub release.
As a result, GitHub isn't just an implementation detail: we can't
retroactively add additional mirrors, and the existing mirror will break
if we ever have to move off GitHub.  Add a get_source endpoint similar to
get_patch so create_release.py can start using it.
@bgilbert
Copy link
Collaborator Author

@bgilbert
Copy link
Collaborator Author

Also cc @xclaesse, who added source_fallback_url generation in #908.

@xclaesse
Copy link
Member

The point in using GitHub as fallback is also in case wrapdb.mesonbuild.com is down, IIRC.

@tp-m
Copy link
Member

tp-m commented Nov 25, 2025

What do you need from me here? Just deploy the new config on the wrapdb servers?

@bgilbert
Copy link
Collaborator Author

@xclaesse There's no fallback for the wrap itself or the patch zip, so if wrapdb.mesonbuild.com is down the wrap won't install or build in any case.

@tp-m Yes, please deploy the config if the PR merges. (And if you have any thoughts on the PR itself, of course please say so.)

@xclaesse
Copy link
Member

@xclaesse There's no fallback for the wrap itself or the patch zip, so if wrapdb.mesonbuild.com is down the wrap won't install or build in any case.

For the wrap itself it's not a big deal because projects commit them. But it's a fair point that we don't write patch_fallback_url, so all wraps would be unusable if wrapdb.mesonbuild.com is down.

Maybe we should add patch_fallback_url=https://github.com/mesonbuild/wrapdb/releases/download/$1/$1_patch.zip in create_release.py.

That said, we can merge (and deploy) this, we can have the discussion about changing the wrap generator in another PR.

@bgilbert
Copy link
Collaborator Author

Oh, that's a good thought. I'll add patch_fallback_url in the followup PR.

@eli-schwartz
Copy link
Member

The point in using GitHub as fallback is also in case wrapdb.mesonbuild.com is down, IIRC.

The point in uploading copies of source tarballs to GitHub was certainly not to handle the case where WrapDB.mesonbuild.com is down -- it was to handle the case where upstream websites are down. The source url never passed through the wrapdb redirector to begin with.

That being said I think I agree that this change doesn't seem entirely necessary -- there's no benefit as far as I can tell for this indirection. If we actually wanted to...

As a result, GitHub isn't just an implementation detail: we can't retroactively add additional mirrors, and the existing mirror will break if we ever have to move off GitHub

... do this, then it wouldn't matter because all historical fallback sources would still exist on GitHub (unless we chose to salt the earth on our way out by deleting all organization assets from GitHub instead of simply archiving and making it all read only).

For the *.wrap files, it makes sense to ensure that our redirector service is the single source of truth, because it's how we disseminate new versions.

For the patch_url overlay archives I'm not sure it matters either, though it is easier to have the "primary" functionality of a wrap go through our own endpoints as there's less to change if/when we migrate again.

But for the fallback sources, we are literally just using GitHub as an additional CDN / backup mirror, it's not even critical to begin with, and if we did switch service providers I think we would need to reevaluate whether we want to (or can) provide additional backup mirroring at all.

@bgilbert
Copy link
Collaborator Author

You're right that it isn't entirely necessary; it's future-proofing. With GitHub as it is today I don't expect we'd ever have a reason to switch, but for an unknown future badly-behaved GitHub (maybe one that charges for storage?) it seems useful to control our own endpoints. Since we already have a mechanism for that, I figure we might as well use it.

(Also, at some point I still want to pursue using the source mirror by default, to reduce the load on upstream servers. Controlling our own mirror URL would be more important in that eventuality.

Not relevant to this PR, but for the record: that change presupposes a new Meson option allowing the canonical upstream URL to be used instead.)

@eli-schwartz
Copy link
Member

Not relevant to this PR, but for the record: that change presupposes a new Meson option allowing the canonical upstream URL to be used instead.)

Yes. :P

(For Gentoo, it's entirely user defined via $GENTOO_MIRRORS, defaults to the official one if unset, but setting it as GENTOO_MIRRORS="" will suppress mirroring and use the canonical url directly.)

@bgilbert bgilbert merged commit a3a44ce into mesonbuild:master Nov 27, 2025
19 checks passed
@bgilbert bgilbert deleted the get_source branch November 27, 2025 04:49
@bgilbert
Copy link
Collaborator Author

Followup in #2532.

@tp-m
Copy link
Member

tp-m commented Nov 27, 2025

Deployed on both wrapdb machines now.

@bgilbert
Copy link
Collaborator Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants