Repository navigation
Different distributable URL for each platform #274
Description
Is there a way to set up different URLs for each platform (Darwin/Linux)?
something along the way:
distributable:
darwin:
url: https://github.com/pkgxdev/darwin/brewkit/archive/refs/tags/v{{ version }}.tar.gz
linux:
url: https://github.com/pkgxdev/linux/brewkit/archive/refs/tags/v{{ version }}.tar.gz
Activity
jhheider commentedon Jan 14, 2024
there's not. it'd be unusual to have different sources for different platforms, but not impossible. you'd more likely be loading an sdk or something else such as flutter.dev where you curl a specific archive based on env. or you can use a git url to check out the whole repo and go from there.
krzyzanowskim commentedon Jan 14, 2024
unusual, and a thing I'm dealing with
That has another implication, that is versioning may be different for each platform, eg 1.0.0 is available for darwin, but 0.9.0 for linux - such disparity happens. Is there a workaround to handle that? (also happens in real)
jhheider commentedon Jan 14, 2024
what package are we talking about? it sounds like maybe those need to be different packages?
krzyzanowskim commentedon Jan 14, 2024
swift pkgxdev/pantry#4840
jhheider commentedon Jan 14, 2024
Ah, yes. Swift is a tough one. We've looked at packaging swiftup (iirc), and tried packaging swift builds. Might need to be two packages. Maybe
swift.org/platform?krzyzanowskim commentedon Jan 14, 2024
is this a convention used elsewhere? I'm thinking how discoverable is it
jhheider commentedon Jan 14, 2024
It's not. Swift will be the first package that requires this.
@mxcl as a life-long swift adherent, what options would you explore here?
mxcl commentedon Jan 14, 2024
k the referenced package is not building from source, it is using a pre-built (but freely distributable) vendor built package.
Unless I'm mistaken?
We do want to support this. We have this PR to do the same for rust for example. We also do the same for bun already since it required a custom build of zig to build from source and that was super early so we just punted on it.
In general I am fine with using vendored sources as long as we trust the vendor. Ideally the vendor will sign the sources with GPG (or something better) and ofc Apple do so!
So let me finish of the vendoring YAML shape and mechanism. Or in the meantime you can copy what we do with bun and
curlthe vendor’d binary in the build script.Different versions for different platforms? That however is more problematic and not something we have seen before. While on the one hand it makes perfect sense that fixes or additions may be platform specific, in general open source just tags the version for all platforms anyway. I'll look deeper.
krzyzanowskim commentedon Jan 14, 2024
I think I manged per platform setup of vendored swift binaries. I struggle with the linux runtime tho https://github.com/pkgxdev/pantry/actions/runs/7520712858/job/20470685734?pr=4840 where it requires certain glibc, and now I'm not sure how to handle that situation. Vendored package is made for a distribution and version, it probably won't work properly everywhere. the
pkgdev/pkgxdocker image seems to beDebian GNU/Linux 10, and now, how do I restrict linux package to these supported?mxcl commentedon Jan 24, 2024
linux pkgx has some “pre requisite” deps, the main one is glibc >=23.
We aim to provide these ourselves eventually, but currently that's the state of it. Swift for Ubuntu 18.04 is provided by Apple and that has the right glibc so I've been trying to get our swift package yml to use that.