summaryrefslogtreecommitdiff
blob: c2db1bfc52323a1fd8323aa7fe04cd0aca568576 (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
211
212
213
214
215
216
217
218
219
220
221
# 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.

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="6" ebuild.

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 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. You are committing a new package to the tree. What will you have in
    the KEYWORDS variable?

docs: devmanual

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

21.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 )"

21.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
  }

21.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
  }

21.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.