1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
# Copyright 1999-2017 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
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 the OpenSSL
library. 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.
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
# 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
# Extra settings for when SSL is enabled
if [ "`use ssl `" ] ; then
# blah
fi
docs: devmanual
6.d
# 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.e
# 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
# 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
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
to the previously mentioned server application?
docs: devmanual
10. 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
be installed from an ebuild?
docs: PMS
13. On Gentoo Linux systems, what is the purpose of /usr/local/bin?
docs: devmanual
14. 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
the KEYWORDS variable?
docs: devmanual
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
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
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
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
16. 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
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:
# 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:
inherit bash-completion-r1
IUSE="bash-completion"
src_install() {
default
use bash-completion && dobashcomp contrib/bash-completion/foo
}
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:
IUSE="foobar"
RDEPEND="foobar? ( dev-libs/libbar )"
DEPEND="${RDEPEND}"
src_install() {
default
if ! use foobar; then
rm "${ED}"/usr/bin/foobar || die
fi
}
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
flags to control all of them.
|
GitWeb