-
Notifications
You must be signed in to change notification settings - Fork 47
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
Improve disable by architecture #760
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #760 +/- ##
==========================================
+ Coverage 87.17% 87.18% +0.01%
==========================================
Files 29 29
Lines 2970 2982 +12
==========================================
+ Hits 2589 2600 +11
- Misses 381 382 +1
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
@davidrohr @martenole @awegrzyn: this should allow us to say that we do not want to bother about OpenSSL on anything but slc7. Either by stating:
which will simply disable the package on anything which is not slc7, or by saying:
which will consider the @awegrzyn could you please have a look? In principle this allows us to drop the |
@TimoWilken could you cross check this makes sense? |
@ktf : thx, I think this makes a lot of sense (haven't tested it myself though). |
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.
This looks useful to me!
This allows us to define that a given package can only be built on certain architectures. This is done via the architecture tag, e.g.: architecture: slc7 # build on slc7 only architecture: (?!osx) # Do not build on macOS architecture: (slc7|slc6) # Only slc6 and slc7 This avoids having to specify in every dependent of the package the conditional requirement string. It also has the advantage that when a package is disabled, but still present on the system because
This allows people to define system requirements also for packages which have a recipe. It also falls back to prefer_system_check when system_requirement_check is missing. This will allow us, for example to say: system_requirement: (ubuntu|osx) for packages which want to pick up from the system on those two architectures, e.g. openssl.
52b7718
to
f43ac2e
Compare
No description provided.