summaryrefslogtreecommitdiff
blob: 8ed3e4180fe162e09949fe8d6350afcbe2ed46d2 (plain)
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
# 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.