diff options
author | 2017-02-24 15:57:30 +0100 | |
---|---|---|
committer | 2017-02-26 10:54:31 +0100 | |
commit | d9b5f58f66a8d710f3b54bfc150c1cec765b9fcc (patch) | |
tree | 3c27138bf4c3be7597030187c4e85955e15ed2ec | |
parent | end quiz: s/local scope/phase scope/ (diff) | |
download | comrel-d9b5f58f66a8d710f3b54bfc150c1cec765b9fcc.tar.gz comrel-d9b5f58f66a8d710f3b54bfc150c1cec765b9fcc.tar.bz2 comrel-d9b5f58f66a8d710f3b54bfc150c1cec765b9fcc.zip |
end-quiz: Combine KEYWORDS questions into a single number
They are quite related, so it seems more reasonable to have them
combined. Furthermore, it reduces the apparent question number!
-rw-r--r-- | recruiters/quizzes/end-quiz.txt | 58 |
1 files changed, 29 insertions, 29 deletions
diff --git a/recruiters/quizzes/end-quiz.txt b/recruiters/quizzes/end-quiz.txt index 14b5df5..7e1c1aa 100644 --- a/recruiters/quizzes/end-quiz.txt +++ b/recruiters/quizzes/end-quiz.txt @@ -133,64 +133,64 @@ docs: devmanual docs: devmanual -15. You are committing a new package to the tree. What will you have in - the KEYWORDS variable? +15.a. You are committing a new package to the tree. What will you have in + the KEYWORDS variable? docs: devmanual -16. You are bumping foomatic's ebuild from version 1.2 to version - 1.3. The new release contains bugfixes and new - functionality. The current KEYWORDS for 1.2 are - "x86 sparc ~mips amd64" -- what will KEYWORDS be for - the new 1.3 ebuild? +15.b. You are bumping foomatic's ebuild from version 1.2 to version + 1.3. The new release contains bugfixes and new + functionality. The current KEYWORDS for 1.2 are + "x86 sparc ~mips amd64" -- what will KEYWORDS be for + the new 1.3 ebuild? docs: devmanual -17. You are bumping foomatic's ebuild from version 1.3 to 1.4. The - new release extends functionality and introduces a new - dependency on libfnord version 1.2 or later. The - KEYWORDS for foomatic-1.3 are "x86 sparc ~mips amd64" - and the KEYWORDS for libfnord-1.2 are "x86 ~sparc" -- - what will you do? +15.c. You are bumping foomatic's ebuild from version 1.3 to 1.4. The + new release extends functionality and introduces a new + dependency on libfnord version 1.2 or later. The + KEYWORDS for foomatic-1.3 are "x86 sparc ~mips amd64" + and the KEYWORDS for libfnord-1.2 are "x86 ~sparc" -- + what will you do? docs: devmanual -18. You are bumping foomatic's ebuild from version 1.4 to 1.5. This - release introduces new optional support for the libgerbil - library, which you are controlling via the gerbil global - USE flag. Unfortunately libgerbil is full of code which - doesn't work properly on big endian systems, and so has - "-sparc -mips" in the KEYWORDS. How will you handle this? +15.d. You are bumping foomatic's ebuild from version 1.4 to 1.5. This + release introduces new optional support for the libgerbil + library, which you are controlling via the gerbil global + USE flag. Unfortunately libgerbil is full of code which + doesn't work properly on big endian systems, and so has + "-sparc -mips" in the KEYWORDS. How will you handle this? docs: devmanual -19. You are bumping foomatic's ebuild from version 1.5 to version - 2.0. This new version is a massive rewrite which introduces - huge changes to the build system, the required libraries - and how the code works. What will you do for KEYWORDS here? +15.e. You are bumping foomatic's ebuild from version 1.5 to version + 2.0. This new version is a massive rewrite which introduces + huge changes to the build system, the required libraries + and how the code works. What will you do for KEYWORDS here? docs: devmanual -20. Your package only builds with newer gcc (e.g. >gcc-4.7). +16. Your package only builds with newer gcc (e.g. >gcc-4.7). How do you ensure that the user uses an appropriate compiler to build the package? Under which circumstances should you avoid this check and how? docs: devmanual -21. When should USE flags be used? What are the cases where they should be +17. When should USE flags be used? What are the cases where they should be avoided? Consider the following examples. Explain what is wrong in them and how would you improve them. docs: devmanual, common sense -21.a. A large C++ application with long build time has: +17.a. A large C++ application with long build time has: # libcxx can be optionally used at run time via -stdlib=libc++ IUSE="libcxx" DEPEND="" RDEPEND="libcxx? ( dev-libs/libcxx )" -21.b. A large package with long build time has: +17.b. A large package with long build time has: inherit bash-completion-r1 IUSE="bash-completion" @@ -200,7 +200,7 @@ docs: devmanual, common sense use bash-completion && dobashcomp contrib/bash-completion/foo } -21.c. A package unconditionally installs 'foobar' executable which links +17.c. A package unconditionally installs 'foobar' executable which links to libbar. The ebuild maintainer wanted to make it optional. He used the following code: @@ -215,7 +215,7 @@ docs: devmanual, common sense fi } -21.d. A package has numerous configure switches which control a number +17.d. A package has numerous configure switches which control a number of optional features. All of them are enabled by default. They do not have any external dependencies, and do not affect the package size significantly. The ebuild author has added over 20 local USE |