Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to condition build dependencies according to the pkg version #319

Open
felipecrs opened this issue Mar 8, 2024 · 2 comments
Open

Comments

@felipecrs
Copy link
Contributor

For example, openjdk.org@11 needs llvm.org<16 while openjdk@16 works fine with llvm.org<17.

And I think it makes a lot of sense. Someday some other package may require a different build dependency set that is will no longer build previous versions of the pkg, and this feature may come in handy.

Refs pkgxdev/pantry#5472 (comment)

@mxcl
Copy link
Member

mxcl commented Mar 9, 2024

Yes this is certainly needed.

Doing it for build deps only is easier than for runtime (it makes the graph calculation significantly more complex, potentially unsolvable even, which is part of the reason other package managers can get themselves into a state sometimes).

@felipecrs
Copy link
Contributor Author

(it makes the graph calculation significantly more complex, potentially unsolvable even, which is part of the reason other package managers can get themselves into a state sometimes).

I am not familiar with the way how libpkgx works under the hoods, but a silly suggestion which may potentially not be even applicable would be to publish some kind of stripped, resolved manifest alongside each package version published to https://dist.pkgx.dev/.

The idea would be to leave dependencies resolution (like applying conditions to runtime dependencies) be done in build time. When installing the pkg, pkgx would only need to resolve the version spec and download such manifest to get a list of the dependencies.

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

No branches or pull requests

2 participants