-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
split shared library to dedicated package libzlib #52
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
@ocefpaf this is ready for a review |
host: | ||
run: | ||
run_constrained: | ||
- zlib {{ version }} *_{{ build_num }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this just
- {{ pin_subpackage('zlib', exact=True) }}
? Since the zlib
output has {{ pin_subpackage('libzlib', exact=True) }}
then all builds that satisfy the constraint should be those from {{ pin_subpackage('zlib', exact=True) }}
either way (and we shouldn't care about build from other channels when comparing build numbers).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. It's a chicken and egg problem. conda-build doesn't know about the PKG_HASH of zlib
until libzlib
has been rendered, but rendering libzlib
needs the PKG_HASH of zlib
if we use exact=True
.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)