summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'recruiters/quizzes/end-quiz.txt')
-rw-r--r--recruiters/quizzes/end-quiz.txt210
1 files changed, 0 insertions, 210 deletions
diff --git a/recruiters/quizzes/end-quiz.txt b/recruiters/quizzes/end-quiz.txt
deleted file mode 100644
index 8ed3e41..0000000
--- a/recruiters/quizzes/end-quiz.txt
+++ /dev/null
@@ -1,210 +0,0 @@
-# Copyright 1999-2018 Gentoo Foundation
-# This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
-# https://creativecommons.org/licenses/by-sa/3.0/
-Ebuild development (end of mentoring) quiz
-Revision 1.4.8 - 2 August 2018
-
-
-Answer in whatever length necessary for completeness.
-Review documentation. Consult your mentor if you're unable to locate answers.
-Do not discuss these questions and their answers in public. Do not publish or
-share any private conversation with your mentor or recruiter.
-
-This quiz is based largely on ciaranm's bash quiz -- much thanks to
-him for the original and for extensive helpful feedback.
-
-
-1. You are writing an ebuild for the foomatic package. Upstream calls
- the current version "1.3-7b" (but this is _not_ a beta release).
- How would the ebuild be named? What's wrong with the ebuild
- snippet below and how should this be written to aid
- maintainability?
-
- SRC_URI="https://foomatic.example.com/download/foomatic-1.3-7b.tar.bz2"
- S=${WORKDIR}/foomatic-1.3-7b
-
-docs: devmanual
-
-2. You have a patch for foomatic which adds TLS support using either
- OpenSSL or LibreSSL libraries.
- The dependency is optional and controlled at build time.
- Assuming that foomatic uses an autotools based build system
- provide most probable changes required in an EAPI=7 ebuild.
-
-docs: devmanual
-
-3. What's the difference between global and phase scope in an ebuild?
-
-docs: PMS
-
-4. Why should an external application (for example sed/grep) not be
- called in global scope? What alternative methods can be used?
-
-docs: devmanual
-
-5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
- inside SRC_URI, DEPEND, etc?
-
-docs: devmanual
-
-6. Explain what's incorrect about the following code snippets and suggest
- an alternative.
-
-6.a
- # Upstream does not support user-specified CFLAGS
- unset CFLAGS
-
-docs: devmanual
-
-6.b
- # Extra settings for when SSL is enabled
- if [ "`use ssl `" ] ; then
- # blah
- fi
-
-docs: devmanual
-
-6.c
- # Extra options for configure
- use jpeg && myconf="--enable-jpeg" \
- || myconf="--disable-jpeg"
- use png && myconf="${myconf} --enable-png" \
- || myconf="${myconf} --disable-png"
- use gif && myconf="${myconf} --enable-gif89a" \
- || myconf="${myconf} --disable-gif89a"
- econf ${myconf}
-
-docs: devmanual
-
-6.d
- # If we USE foo, we need to DEPEND upon libfoo. Unfortunately
- # libfoo is completely broken on some archs
- DEPEND="!x86? ( !amd64? ( !ppc? ( foo? ( >=dev-libs/libfoo-1.2 ) ) ) )"
-
-docs: devmanual
-
-6.e
- # If USE=fnord is enabled, make extra targets:
- use fnord && ( emake fnordification || die "it broke" )
-
-docs: devmanual
-
-
-7. You're writing an ebuild and init script for a server application
- that needs networking to be available when started and can also
- use a system logger if one is available. How should this be
- written in the init script?
-
-docs: devmanual
-
-8. What is the 'Gentoo way' of allowing the user to pass other options
- to the previously mentioned server application?
-
-docs: devmanual
-
-9. What is the 'Gentoo way' of globally setting environment variables
- for all users?
-
-docs: devmanual
-
-10. Which directory should manual (man) pages be in and how should they
- be installed from an ebuild?
-
-docs: PMS
-
-11. On Gentoo Linux systems, what is the purpose of /usr/local/bin?
-
-docs: devmanual
-
-12. When should you use || die "msg" with commands/functions?
- Could || die always be moved inside those functions/commands?
-
-docs: devmanual
-
-13.a. You are committing a new package to the tree. What will you have in
- the KEYWORDS variable?
-
-docs: devmanual
-
-13.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
-
-13.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
-
-13.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
-
-13.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
-
-14. Your package fails to build with older versions of 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
-
-15. 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
-
-15.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 )"
-
-15.b. A large package with long build time has:
-
- inherit bash-completion-r1
- IUSE="bash-completion"
-
- src_install() {
- default
- use bash-completion && dobashcomp contrib/bash-completion/foo
- }
-
-15.c. A package unconditionally installs 'foobar' executable which links
- to libbar. The ebuild maintainer wanted to make it optional.
- He used the following code:
-
- IUSE="foobar"
- RDEPEND="foobar? ( dev-libs/libbar )"
- DEPEND="${RDEPEND}"
-
- src_install() {
- default
- if ! use foobar; then
- rm "${ED}"/usr/bin/foobar || die
- fi
- }
-
-15.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
- flags to control all of them.