Skip to content

Conversation

@IanButterworth
Copy link
Member

i.e. for JLLs whose package version is most likely not the same as the upstream version.

Currently we don't record the upstream version reliably from BB, but it's proving painful for advisory tracking (cc. @mbauman)

Here ImageMagick_jll has been modified to have a made up upstream_version field in its Project.toml here

Screenshot 2025-08-27 at 1 22 02 PM

@jeremiahpslewis
Copy link
Contributor

Would this be a good place / time to also add a canonical name field for easier matching with upstream?

@IanButterworth
Copy link
Member Author

Yeah and that is within the discussion in JuliaPackaging/BinaryBuilder.jl#639

@mbauman
Copy link
Member

mbauman commented Sep 3, 2025

Pretty much everything I thought I knew about JLLs was wrong. This is wildly challenging.

  • There are JLLs that redistribute many upstream components, all bundled together (and not split out into separate dependent JLLs). For example, https://github.com/JuliaBinaryWrappers/oneAPI_Support_jll.jl.
  • There are JLLs that combine multiple forks for different platforms at potentially different versions. For example, [email protected]+0 ships OpenBSD/ssh version 10.0p1 and PowerShell/Win32-OpenSSH version 9.5.0.0p1 (for both 32- and 64-bit, pay no mind to the Win32 there).
  • There are JLLs that ship different versions from the same upstream project. For example, [email protected]+0 ships git-for-windows/git version 2.51.0 for 64-bit and 2.48.1 for 32-bit (this is in addition to shipping git/git for other platforms).
  • There are JLLs that were not built by BinaryBuilder, but instead have manually crafted Artifacts that may point somewhere other than a GitHub release asset. For example, Gurobi_jll provides its Artifact binaries directly from anaconda's distribution.

@DilumAluthge
Copy link
Member

I'm assuming @giordano has already seen this discussion, but pinging him just in case

@DilumAluthge
Copy link
Member

Instead of a single version number, could we store a dict with more detailed info?

@giordano
Copy link
Member

giordano commented Sep 3, 2025

While adding stuff to the registry can be useful, I feel like for what Matt wants it'd be better to dump all the info we want into a file in the JLL repo, so that we don't need to care about cluttering the registry. Someone needs to champion designing the data we need and the format. I mentioned in JuliaPackaging/BinaryBuilder.jl#639 (comment) that some information (perhaps all?) has to be platform-specific, as Matt realised the hard way today.

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

Labels

None yet

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

5 participants