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

Support noarch recipes. #24

Merged
merged 2 commits into from
Nov 14, 2018
Merged

Support noarch recipes. #24

merged 2 commits into from
Nov 14, 2018

Conversation

jdblischak
Copy link
Collaborator

@isuruf
Copy link
Contributor

isuruf commented Nov 14, 2018

license file path is the same now for unix and windows

@jdblischak
Copy link
Collaborator Author

license file path is the same now for unix and windows

@isuruf When did that change happen? Was it implemented in conda-forge/r-base-feedstock#61?

And just to confirm, by the same file path, you mean that Windows now also uses /lib/R/share/licenses/?

@isuruf
Copy link
Contributor

isuruf commented Nov 14, 2018

Yes and yes

Change to Windows r-base installation path implemented in
conda-forge/r-base-feedstock#61
@jdblischak
Copy link
Collaborator Author

@isuruf Updated to always use the same file path

@bgruening
Copy link
Owner

Muha, you guys are amazing!

@bgruening bgruening merged commit 51b5950 into bgruening:master Nov 14, 2018
@jdblischak
Copy link
Collaborator Author

@isuruf @bgruening I just realized, isn't changing the installation path for R 3.5.1 but not R 3.4.1 going to cause some issues for Windows builds? For older recipes with GPL licenses, the license file will be properly packaged for R 3.4.1 but not for R 3.5.1. For new recipes with GPL licenses, the license file will be packaged properly for R 3.5.1 but not for R 3.4.1.

Do I understand the situation correctly? Is there a way we can fix this? One option would be to build a new version of R 3.4.1 on a branch that uses the new path, but that's likely to be difficult given all the recent changes in conda-forge. Is there anyway we can use a selector in the recipe to distinguish between the builds for R 3.4.1 and 3.5.1?

@bgruening
Copy link
Owner

@jdblischak we skipped 3.4.1 for now to avoid the problem with rebuilding. As 3.4.1. would also not be rebuild against GCC 7.

@isuruf
Copy link
Contributor

isuruf commented Nov 14, 2018

FYI. you can do # [win and r_base=='3.4.1'] to distinguish between 3.4.1 and 3.5.1

@jdblischak
Copy link
Collaborator Author

we skipped 3.4.1 for now to avoid the problem with rebuilding. As 3.4.1. would also not be rebuild against GCC 7.

@bgruening Thanks for the explanation. I had missed PR conda-forge/conda-forge-pinning-feedstock#148

However, this still means that existing recipes with GPL licenses need to be updated for the license to be packaged for Windows. Is this something we should explore doing with the autotick bot? Or with separate PRs?

@jdblischak
Copy link
Collaborator Author

FYI. you can do # [win and r_base=='3.4.1'] to distinguish between 3.4.1 and 3.5.1

@isuruf Good to know. Thanks!

@isuruf
Copy link
Contributor

isuruf commented Nov 14, 2018

However, this still means that existing recipes with GPL licenses need to be updated for the license to be packaged for Windows. Is this something we should explore doing with the autotick bot? Or with separate PRs?

PRs to the bot (to do this automatically) are welcome.

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.

None yet

3 participants