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
|
# Copyright 1999-2016 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.4 - 21 August 2015
Answer in whatever length necessary for completeness.
Review documentation. Consult your mentor if you're unable to locate answers.
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 SSL support that is optional
at build time. Assuming that foomatic uses an autotools based build system
provide most probable changes required in an EAPI="0" ebuild. What should
be done for the ebuild in case it uses EAPI="5"?
docs: devmanual
3. What's the difference between local and global 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 don't 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
# foo 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. Why are 'head -5' and 'tail -5' bad? What should be used instead?
docs:
9. 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
10. What is the 'Gentoo Way' of allowing the user to pass other options
to the previously mentioned server application?
docs: devmanual
11. What is the 'Gentoo Way' of globally setting environment variables
for all users?
docs: devmanual
12. What directory should be used for application-generated
non-temporary data?
docs: devmanual
13. Which directory should manual (man) pages be in and how should they
be installed from an ebuild?
docs: PMS
14. On Gentoo Linux systems, what is the purpose of /usr/local/bin?
docs: devmanual
15. When should you use || die "msg" with commands/functions?
Could || die always be moved inside those functions/commands?
docs: devmanual
16. You are committing a new package to the tree. What will you have in
the KEYWORDS variable?
docs: devmanual
17. 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
18. 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
19. 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
20. 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
21. 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
|
GitWeb