$Id$
$Revision$

Lets go to the next big part of your application - the check of Tasks &
Skills. Similar to the P&P we just finished it is also splitted, this
time in 3 steps. These steps are 2 parts of Questions together with a
severe check of your package(s).

There is also a place where you can go and upload your package. The
archive at that site works exactly the same as the Debian archive, in
fact it uses the same software behind the scene. So you can take this as
the opportunity to get used to uploads and the stuff that happens with
your packages, you are not just left alone after your NM without any
knowledge what exactly you need to do to get a package into the
archive.
For more information please read http://dak.ganneff.de/dak.txt and also
the email you should get in a short timeframe from that archive. It will
tell you your accountname there, and a few other details you may want to
know.

After we finished the two steps with the questions I will get the
package you uploaded to that archive and check that. So please take the
time until then and prepare the best package out of it. :)

Finally, the first half of the questions:

If you have filed bugreports (with patches) to the BTS with respect to
packaging issues, please tell me bug numbers, so I can check them.

 0. What is the best way to check that your Build-Depends Line contains
    everything required to build your package?

 1. Please explain me what a virtual package is. Where can you find a
    list of defined virtual packages?

 2. What does it mean for a package to have a line like 
    "Architecture: i386 alpha powerpc" in the control file?
    Do you have to provide binary packages for all these
    architectures if you upload your package?
    What is the difference between "Architecture: all" and
    "Architecture: any"?

 3. How do you manage new upstream releases?

 4. There is a bug in your package, fixed in Upstream CVS/development
    branch. What do you do with it?

 5. What do you do if Upstream releases a tarball once every year and
    then distributes minor revisions only in the form of patches? How do
    you manage your package then?

 6. What is the difference between native packages and non-native
    packages?

 7. What is an epoch? When would you use one?

 8. Explain the difference between Depends, Recommends and Suggests.

 9. How does Debian handle run levels? 
    What runlevels are related? How does this interact with users' local
    modifications?
    What should packages which require starting up and shutting down
    (like daemons do) do?

 A. Tell me the differences between /usr/share and /usr/lib.

 B. Please list some good reasons for a package split.

 C. What would you need to do if upstream changed the name of the
    application?  What would you do to assure smooth upgrades? 

 D. What is Pre-depends for? Why should you avoid it?

Weeh, that is the first half. Take your time to answer them, but please
don't take forever. There is more waiting for you and we all want to get
this to a good end, do we?