summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMikle Kolyada <zlogene@gentoo.org>2018-08-02 14:29:57 +0300
committerMikle Kolyada <zlogene@gentoo.org>2018-08-02 15:19:53 +0300
commitf64227f6eac791bb27c8a9cb6c61bb1e98d27cbd (patch)
tree86ced1aae1c578c5a7581ed4950611bcbd9f4f4f
parentNote on confidentiality of quiz answers and recruitment (diff)
downloadcomrel-f64227f6eac791bb27c8a9cb6c61bb1e98d27cbd.tar.gz
comrel-f64227f6eac791bb27c8a9cb6c61bb1e98d27cbd.tar.bz2
comrel-f64227f6eac791bb27c8a9cb6c61bb1e98d27cbd.zip
end-quiz: remove Q6.a and Q7
- add LibreSSL and bump Q2 to the EAPI=7 - remove question about basic shell tools (useless in the scope of Gentoo) - remove question about /var - remove Q6.a as there is no practical use of it - update revision and copyright
-rw-r--r--recruiters/quizzes/end-quiz.txt68
1 files changed, 27 insertions, 41 deletions
diff --git a/recruiters/quizzes/end-quiz.txt b/recruiters/quizzes/end-quiz.txt
index a6be43f..8ed3e41 100644
--- a/recruiters/quizzes/end-quiz.txt
+++ b/recruiters/quizzes/end-quiz.txt
@@ -1,8 +1,8 @@
-# Copyright 1999-2017 Gentoo Foundation
+# 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.7 - 24 February 2017
+Revision 1.4.8 - 2 August 2018
Answer in whatever length necessary for completeness.
@@ -25,10 +25,11 @@ him for the original and for extensive helpful feedback.
docs: devmanual
-2. You have a patch for foomatic which adds TLS support using the OpenSSL
- library. The dependency is optional and controlled at build time.
+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="6" ebuild.
+ provide most probable changes required in an EAPI=7 ebuild.
docs: devmanual
@@ -50,18 +51,12 @@ docs: devmanual
an alternative.
6.a
- # This ebuild doesn't like the -mcpu=ultrasparc CFLAG, so drop to v9
- CFLAGS=${CFLAGS/-mcpu=ultrasparc/-mcpu=v9}
-
-docs: devmanual
-
-6.b
# Upstream does not support user-specified CFLAGS
unset CFLAGS
docs: devmanual
-6.c
+6.b
# Extra settings for when SSL is enabled
if [ "`use ssl `" ] ; then
# blah
@@ -69,7 +64,7 @@ docs: devmanual
docs: devmanual
-6.d
+6.c
# Extra options for configure
use jpeg && myconf="--enable-jpeg" \
|| myconf="--disable-jpeg"
@@ -81,66 +76,57 @@ docs: devmanual
docs: devmanual
-6.e
+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.f
+6.e
# If USE=fnord is enabled, make extra targets:
use fnord && ( emake fnordification || die "it broke" )
docs: devmanual
-7. Explain briefly the purpose of the following tools:
- grep, cut, sed, cat, wc, awk
-
-docs: devmanual
-8. You're writing an ebuild and init script for a server application
+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
-9. What is the 'Gentoo Way' of allowing the user to pass other options
+8. What is the 'Gentoo way' of allowing the user to pass other options
to the previously mentioned server application?
docs: devmanual
-10. What is the 'Gentoo Way' of globally setting environment variables
+9. What is the 'Gentoo way' of globally setting environment variables
for all users?
docs: devmanual
-11. What directory should be used for application-generated
- non-temporary data?
-
-docs: devmanual
-
-12. Which directory should manual (man) pages be in and how should they
+10. Which directory should manual (man) pages be in and how should they
be installed from an ebuild?
docs: PMS
-13. On Gentoo Linux systems, what is the purpose of /usr/local/bin?
+11. On Gentoo Linux systems, what is the purpose of /usr/local/bin?
docs: devmanual
-14. When should you use || die "msg" with commands/functions?
+12. When should you use || die "msg" with commands/functions?
Could || die always be moved inside those functions/commands?
docs: devmanual
-15.a. You are committing a new package to the tree. What will you have in
+13.a. You are committing a new package to the tree. What will you have in
the KEYWORDS variable?
docs: devmanual
-15.b. You are bumping foomatic's ebuild from version 1.2 to version
+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
@@ -148,7 +134,7 @@ docs: devmanual
docs: devmanual
-15.c. You are bumping foomatic's ebuild from version 1.3 to 1.4. The
+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"
@@ -157,7 +143,7 @@ docs: devmanual
docs: devmanual
-15.d. You are bumping foomatic's ebuild from version 1.4 to 1.5. This
+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
@@ -166,33 +152,33 @@ docs: devmanual
docs: devmanual
-15.e. You are bumping foomatic's ebuild from version 1.5 to version
+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
-16. Your package fails to build with older versions of GCC (e.g. GCC < 4.7).
+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
-17. When should USE flags be used? What are the cases where they should be
+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
-17.a. A large C++ application with long build time has:
+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 )"
-17.b. A large package with long build time has:
+15.b. A large package with long build time has:
inherit bash-completion-r1
IUSE="bash-completion"
@@ -202,7 +188,7 @@ docs: devmanual, common sense
use bash-completion && dobashcomp contrib/bash-completion/foo
}
-17.c. A package unconditionally installs 'foobar' executable which links
+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:
@@ -217,7 +203,7 @@ docs: devmanual, common sense
fi
}
-17.d. A package has numerous configure switches which control a number
+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