diff options
author | 2019-01-21 17:18:21 +0300 | |
---|---|---|
committer | 2019-01-21 17:25:19 +0300 | |
commit | 05d75253be6015f0361969d4fed9c812bbc86328 (patch) | |
tree | aa9bba972df1da615b7b65ffc53eb44cc7b1fde2 | |
parent | ebuild-quiz: add Q21 about sub-slots usage (diff) | |
download | comrel-05d75253be6015f0361969d4fed9c812bbc86328.tar.gz comrel-05d75253be6015f0361969d4fed9c812bbc86328.tar.bz2 comrel-05d75253be6015f0361969d4fed9c812bbc86328.zip |
merge ebuild and end quizzes into ebuild-maintainer quiz
Signed-off-by: Mikle Kolyada <zlogene@gentoo.org>
-rw-r--r-- | recruiters/quizzes/ebuild-maintainer-quiz.txt | 463 | ||||
-rw-r--r-- | recruiters/quizzes/ebuild-quiz.txt | 217 | ||||
-rw-r--r-- | recruiters/quizzes/end-quiz.txt | 210 |
3 files changed, 463 insertions, 427 deletions
diff --git a/recruiters/quizzes/ebuild-maintainer-quiz.txt b/recruiters/quizzes/ebuild-maintainer-quiz.txt new file mode 100644 index 0000000..aa5b1ed --- /dev/null +++ b/recruiters/quizzes/ebuild-maintainer-quiz.txt @@ -0,0 +1,463 @@ +# Copyright 1999-2019 Gentoo Authors +# Copyright 2016-2019 Amy Liffey +# Copytight 2016-2019 Mikle Kolyada +# This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. +# https://creativecommons.org/licenses/by-sa/3.0/ + +Ebuild maintainer quiz +Revision 2.22.8 - 7 January 2018 + +Answer in whatever length necessary for completeness. +Support your answers with documentation links but avoid redundand citation. +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. + +*** PART I Organizational structure questions + + +1. When is it appropriate to post to the following mailing lists: gentoo-core, + gentoo-dev, gentoo-dev-announce, gentoo-project? Provide examples of topics + that are appropriate for each one of them. + +docs: gentoo.org + +2. Who should be contacted with complaints about specific developers or + projects? Shortly explain the procedure including all levels of appeal. + +docs: comrel policy + +3. What is the proper method for suggesting a wide-ranging feature or + enhancement to Gentoo? Describe the process for getting this feature + approved and implemented. + +docs: GLEPs + +4. What is the purpose of the Gentoo Council? + +docs: GLEPs + +5. What is the Gentoo Foundation? How does one apply for membership and + who are eligible? + +docs: gentoo.org + +6. What are projects? Who can start a new Gentoo project and how is it done? + What is the rationale behind this structure? + +docs: devmanual, GLEPs + +7. What is the devaway system? When should it be used and how to use it? + +docs: wiki + +*** PART II Ebuild technical/policy questions + + +1. You change a package's ebuild to install an init script. Previously, + the package had no init script at all. + Is a revision bump necessary? Why? What about when adding a patch? + What about when adding a dependency? + +docs: devmanual + +2. A user submits a "live" VCS (git, svn ...) ebuild in order to obtain + a bugfix that has not been released yet. What would be a preferable + alternative to such an ebuild? What if there are numerous changes + involved? + +docs: devmanual + +3.a. What is repoman? When should it be used? How would you check for QA + problems with repoman? + +docs: devmanual, wiki + +3.b. A user submits a brand-new ebuild for a new package. What are + the proper steps (including repoman commands) to take to add + this ebuild to ::gentoo repository? What should be in the commit message? + +docs: devmanual, wiki + +4. A user submits an ebuild that has numerous technical problems and + violates policy. How would you handle that situation? + +docs: devmanual + +5. You have a set of new ebuilds that could potentially benefit + from a global USE flag. What steps should be taken before + a new USE flag is implemented? What should be done if the + USE flag only applies to a single package? + +docs: devmanual + +6. What steps are needed to remove a use flag from an ebuild? + +docs: common sense + +7. You are creating an ebuild. Unfortunately, the default 'emake + DESTDIR="${D}" install' call causes numerous access violations. + What are the best long-term and short-term solutions? + +docs: devmanual + +8. You are creating an ebuild that needs a patch. The patch is + nontrivially large - bigger than 20 KiB. Where should + the patch be kept? + +docs: devmanual + +9. You are creating an ebuild for a package whose license does not match + any of the licenses in the 'licenses' directory. What is the proper + course of action? + +docs: GLEPs, devmanual + +10.a. You wish to have an ebuild marked "stable," taking it out of + ~ARCH KEYWORDS. It's a library. What steps should be taken to do so? + +docs: devmanual + +10.b. You wish to mark an ebuild "testing," putting it into ~ARCH + KEYWORDS. It was previously hard-masked in package.mask. + What should be done prior to doing so? + +docs: devmanual + +10.c. You wish to have an ebuild marked "stable." It is a popular + application, but no other ebuilds depend on it. + How would you handle it? + +docs: devmanual + +11. What is the difference between different dependency classes (DEPEND, + RDEPEND and BDEPEND)? When should each of them be used? Provide examples. + +docs: devmanual + +12. You wish to make a change to an ebuild, but you checked the commit + messages and metadata.xml and it appears to be maintained by someone + else. How should you proceed? + +docs: devmanual + +13.a. You find a situation in which an eclass may be useful. What should + you do before implementing such an eclass? + +13.b. What is EXPORT_FUNCTIONS? How should it be used? + Provide examples of its usage. + +docs: devmanual + +14. How can you verify an ebuild has correct run time dependencies + (RDEPEND) for all installed binaries? Provide an example tool calls. + +docs: + +15. How do you deal with a situation in which an ebuild tries to + install a file that is already installed by another package? + +docs: devmanual + +16. Most configure scripts attempt to automatically determine + settings based on the host system. When should the ebuild + specifically override settings? + +docs: devmanual + +17. What is the EAPI version? How does it affect ebuilds and eclasses? + +docs: devmanual, PMS + +18. What is the procedure for removing packages from the tree? + +docs: devmanual + +19. How do keywording and stabilization policies for less often used arches + like ia64 or mips differ from the more common ones like amd64? + +docs: devmanual + +20. You are adding a new major version to the tree that requires users to + follow an upgrade guide. How will you communicate this to the users? + +docs: GLEPs + +21. What are sub-slots and their binding operators? What problem do they + solve in gentoo and when should be used? Provide examples. + +docs: wiki, portage documentation + +22.a. You are about to add a new package. How would you determine the correct + LICENSE? What sources should be consulted for license information, + and which take precedence? + +docs: devmanual + +22.b. The package frobnicate has a 'COPYING' that exactly matches GPL-3. + However, all the source files have the following copyright notice: + + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + What should be the value of LICENSE variable for this package? + +docs: devmanual + +22.c. The package installs both frobnicate executable (licensed GPL-3+) + and libfrobnicate shared library (licensed LGPL-2.1+). What should + be the correct value of LICENSE for this package? + +docs: devmanual + +22.d. The package installs frobnicate executable whose sources indicate GPL-3+ + license. However, you notice that the build process creates a local + static libport.a library that is used to build a part of frobnicate + but is not meant to be installed. The sources of libport.a indicate + LGPL-2.1+ license. What should be the value of LICENSE for this package? + +docs: devmanual + +22.e. A MIT-licensed package includes a CDDL-licensed script. The script is + not installed but it is used during build to generate a Makefile. What + should be the value of LICENSE for this package? + +docs: common sense + +22.f. A BSD-licensed package installs a frobnicate executable. However, after + inspecting the package sources you notice that it uses a single source + file whose license indicates GPL-2+. What would you do? What could be + the LICENSE for this package? + +*** PART ||| Code questions + + +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. + + + +*** Please also submit the following information: + +* Please make sure your OpenPGP public keyblock is available on the keyserver network + hkp://pool.sks-keyservers.net and provide the fingerprint of it below + You should sign your quizzes with your key + https://wiki.gentoo.org/wiki/Project:Gentoo-keys/Generating_GLEP_63_based_OpenPGP_keys + https://wiki.gentoo.org/wiki/GnuPG + +* SSH public key (if you do not have one, please create one) + https://wiki.gentoo.org/wiki/Project:Infrastructure/SSH_Key_Guide + If you don't paste your key inline, make sure it's signed by your + gpg key. + +* Date of birth + +* Where do you live (Town/City, Country) + +* What are your programming/scripting skills, if applicable? + +* What other areas are you experienced in? + +* What other projects have you contributed to, if any? + +* Tell us about yourself. This doesn't need to be strictly + computer-relevant; things like where you're from, + hobbies, job, family, interests... This information will be used + for your public new developer announcement so please mention if + something should not be part of that. diff --git a/recruiters/quizzes/ebuild-quiz.txt b/recruiters/quizzes/ebuild-quiz.txt deleted file mode 100644 index 5c4eefc..0000000 --- a/recruiters/quizzes/ebuild-quiz.txt +++ /dev/null @@ -1,217 +0,0 @@ -# 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 quiz -Revision 1.18 - 21 September 2018 - - -Answer in whatever length necessary for completeness. Support your answers -with documentation links. 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. - - -*** Organizational structure questions - -1. When is it appropriate to post to the following mailing lists: gentoo-core, - gentoo-dev, gentoo-dev-announce, gentoo-project? Provide examples of topics - that are appropriate for each one of them. - -docs: gentoo.org - -2. Who should be contacted with complaints about specific developers or - projects? Shortly explain the procedure including all levels of appeal. - -docs: comrel policy - -3. What is the proper method for suggesting a wide-ranging feature or - enhancement to Gentoo? Describe the process for getting this feature - approved and implemented. - -docs: GLEPs - -4. What is the purpose of the Gentoo Council? - -docs: GLEPs - -5. What is the Gentoo Foundation? How does one apply for membership and - who are eligible? - -docs: gentoo.org - -6. What are projects? Who can start a new Gentoo project and how is it done? - What is the rationale behind this structure? - -docs: devmanual, GLEPs - -7. What is the devaway system? When should it be used and how to use it? - -docs: wiki - - -*** Ebuild technical/policy questions - -1. You change a package's ebuild to install an init script. Previously, - the package had no init script at all. - Is a revision bump necessary? Why? What about when adding a patch? - What about when adding a dependency? - -docs: devmanual - -2. A user submits a "live" VCS (git, svn ...) ebuild in order to obtain - a bugfix that has not been released yet. What would be a preferable - alternative to such an ebuild? What if there are numerous changes - involved? - -docs: devmanual - -3.a. What is repoman? When should it be used? How would you check for QA - problems with repoman? - -docs: devmanual, wiki - -3.b. A user submits a brand-new ebuild for a new package. What are - the proper steps (including repoman commands) to take to add - this ebuild to ::gentoo repository? What should be in the commit message? - -docs: devmanual, wiki - -4. A user submits an ebuild that has numerous technical problems and - violates policy. How would you handle that situation? - -docs: devmanual - -5. You have a set of new ebuilds that could potentially benefit - from a global USE flag. What steps should be taken before - a new USE flag is implemented? What should be done if the - USE flag only applies to a single package? - -docs: devmanual - -6. What steps are needed to remove a use flag from an ebuild? - -docs: common sense - -7. You are creating an ebuild. Unfortunately, the default 'emake - DESTDIR="${D}" install' call causes numerous access violations. - What are the best long-term and short-term solutions? - -docs: devmanual - -8. You are creating an ebuild that needs a patch. The patch is - nontrivially large - bigger than 20 KiB. Where should - the patch be kept? - -docs: devmanual - -9. You are creating an ebuild for a package whose license does not match - any of the licenses in the 'licenses' directory. What is the proper - course of action? - -docs: GLEPs, devmanual - -10.a. You wish to have an ebuild marked "stable," taking it out of - ~ARCH KEYWORDS. It's a library. What steps should be taken to do so? - -docs: devmanual - -10.b. You wish to mark an ebuild "testing," putting it into ~ARCH - KEYWORDS. It was previously hard-masked in package.mask. - What should be done prior to doing so? - -docs: devmanual - -10.c. You wish to have an ebuild marked "stable." It is a popular - application, but no other ebuilds depend on it. - How would you handle it? - -docs: devmanual - -11. What is the difference between different dependency classes (DEPEND, - RDEPEND and BDEPEND)? When should each of them be used? Provide examples. - -docs: devmanual - -12. You wish to make a change to an ebuild, but you checked the commit - messages and metadata.xml and it appears to be maintained by someone - else. How should you proceed? - -docs: devmanual - -13.a. You find a situation in which an eclass may be useful. What should - you do before implementing such an eclass? - -13.b. What is EXPORT_FUNCTIONS? How should it be used? - Provide examples of its usage. - -docs: devmanual - -14. How can you verify an ebuild has correct run time dependencies - (RDEPEND) for all installed binaries? Provide an example tool calls. - -docs: - -15. How do you deal with a situation in which an ebuild tries to - install a file that is already installed by another package? - -docs: devmanual - -16. Most configure scripts attempt to automatically determine - settings based on the host system. When should the ebuild - specifically override settings? - -docs: devmanual - -17. What is the EAPI version? How does it affect ebuilds and eclasses? - -docs: devmanual, PMS - -18. What is the procedure for removing packages from the tree? - -docs: devmanual - -19. How do keywording and stabilization policies for less often used arches - like ia64 or mips differ from the more common ones like amd64? - -docs: devmanual - -20. You are adding a new major version to the tree that requires users to - follow an upgrade guide. How will you communicate this to the users? - -docs: GLEPs - -21. What are sub-slots and their binding operators? What problem do they - solve in gentoo and when should be used? Provide examples. - -docs: wiki, portage documentation - - -*** Please also submit the following information: - -* Please make sure your OpenPGP public keyblock is available on the keyserver network - hkp://pool.sks-keyservers.net and provide the fingerprint of it below - You should sign your quizzes with your key - https://wiki.gentoo.org/wiki/Project:Gentoo-keys/Generating_GLEP_63_based_OpenPGP_keys - https://wiki.gentoo.org/wiki/GnuPG - -* SSH public key (if you do not have one, please create one) - https://wiki.gentoo.org/wiki/Project:Infrastructure/SSH_Key_Guide - If you don't paste your key inline, make sure it's signed by your - gpg key. - -* Date of birth - -* Where do you live (Town/City, Country) - -* What are your programming/scripting skills, if applicable? - -* What other areas are you experienced in? - -* What other projects have you contributed to, if any? - -* Tell us about yourself. This doesn't need to be strictly - computer-relevant; things like where you're from, - hobbies, job, family, interests... This information will be used - for your public new developer announcement so please mention if - something should not be part of that. diff --git a/recruiters/quizzes/end-quiz.txt b/recruiters/quizzes/end-quiz.txt deleted file mode 100644 index 8ed3e41..0000000 --- a/recruiters/quizzes/end-quiz.txt +++ /dev/null @@ -1,210 +0,0 @@ -# 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. |