Ebuild development quiz
Revision 1.11.1 - 01 January 2007
Answer in whatever length necessary for completeness.
Review documentation. Consult your mentor if you're unable to locate answers.

*** Organizational structure questions

1. When is it appropriate to post to gentoo-core rather than gentoo-dev?

2. Who should be contacted with complaints about specific developers or
	projects?

3. What is the proper method for suggesting a wide-ranging feature or
	enhancement to Gentoo?

4. What is the purpose of the Gentoo Council?

5. What is the purpose of the Gentoo project structure?

6. What is the purpose of herds?

*** 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?

2. A user submits a "live" CVS ebuild. What would be a preferable
	alternative to such an ebuild?

3. (a) What is repoman? How would you check for QA problems with 
   repoman?

   (b) A user submits a brand-new ebuild for a new package. What are the
	proper steps (including repoman/cvs commands) to take to add
	this ebuild to the tree?

4. A user submits an ebuild that has numerous technical problems and
	violates policy. How would you handle that situation?

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?

6. You're creating an ebuild. Unfortunately, the ebuild's 'make install'
	target causes numerous access violations. What is the best 
	course of action to take to have a clean, straightforward
	ebuild?

7. You're creating an ebuild that needs a patch. The patch is 
	nontrivially large - bigger than 20kbytes. Where should
	the patch be kept?

8. You're creating an ebuild that has its own license - one that
	doesn't exist in /usr/portage/licenses/. What is the proper
	course of action?

9. (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?

   (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?

   (c) You wish to have an ebuild marked "stable." It is a popular
	application, but no other ebuilds depend on it.
	What should be done first?

10. You're committing a user-submitted ebuild. What should be in the
	initial ChangeLog?

11. What is the difference between DEPEND and RDEPEND?

12. You wish to make a change to an ebuild, but you checked
	ChangeLogs and metadata.xml and it appears to be maintained by 
	someone	else. How should you proceed?

13. You find a situation in which an eclass may be useful. What should
	you do before implementing such an eclass?

14. You find a package that will not build on some architectures without
	PIC (-fPIC) code in the shared libraries. What is the proper way
	to handle this situation?

15. What do you do when you'd like to have a package you maintain
	tested or marked stable on other architectures?

16. How can you verify an ebuild has correct run time dependencies
	(RDEPEND) for all installed binaries?

17. How do you deal with a situation in which an ebuild wishes to
	install a file already installed by another package?

18. Most configure scripts attempt to automatically determine
	settings based on the host system. When should the ebuild
	specifically override settings?

*** Please also submit the following information:

* GPG public key ID (if you do not have one, please create one)

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