On 10164 March 1977, Brian Nelson wrote: > 1. debhelper > I've found that some applicants don't really understand debhelper > very well. I'd like to add a question that asks what debhelper is, > what purposes it serves, what alternatives are available, and how to > use it properly (debian/compat, build-depends, ${misc:Depends}, > basically the stuff covered in > http://lists.debian.org/debian-devel-announce/2003/03/msg00002.html). Isnt that more for the package check? 98% of them are having dh_ packages, so let them prepare a really good one of it. Next step of course redo the whole stuff without dh. > 2. version control > I can't remember where I wanted to go with this one. I guess the > idea was that applicants should have a basic understanding of > cvs/subversion/arch, and maybe should understand the benefits of > maintaining packages with version control. Naa. Everyone can handle that how he likes it most. Even if one prints the stuff out and makes changes with a red pencil. I dont think thats a thing to add to NM. > 3. debconf, ucf > I think applicants should have an understanding of when to use > debconf in their packages, how to use it, and when ucf can be used in > conjunction with it. ucf, hrmm. One can enhance the question we already have that points to debconf, so it includes more debconf and also ucf related stuff. > 4. debconf notes vs. debian/NEWS > Which to use... See above. > 5. testing migration > How packages migrate to testing, how to diagnose and fix migration > problems, and where to ask for help... Thats in the urgency question together with the "Many Debian suites" one. > 6. "pristine" tarballs > This one's pretty straight-forward. How to ensure a package's > orig.tar.gz is "pristine" (aka md5sums match), what to do if upstream > doesn't distribute a tar.gz (tar.bz2, etc.) ... Ok. > 7. library packaging > I'd like to see some more questions about library packaging, since it > can be very tricky and many people, including existing developers, > make mistakes with it. In particular sonames, shlibs, > ${shlibs:Depends}, dpkg-shlibdeps, and especially proper use of > dh_makeshlibs. Not everyone will package libs later. The basic questions I have should give them the right directions, including a reading of the lib guides we have, so they remember later where too look. Anything more is IMO too much, some AMs already strip (most of) the library questions. > That last one reminds me--the question: > Why does a foo-dev package depends on foo? > Why is it fooX-dev and not foo-dev in some cases? > is confusing. Many applicants read that and say, "huh?" I think the > question is trying to ask why libraries are split into libblahX and > libblah-dev packages, and why it can be useful to have multiple -dev > versions for a library. Joerg, can you please clarify? Yes, it asks why there are sometimes multiple version of one dev package. -- bye Joerg [Es geht doch nichts ueber deutsche Uebersetzungen] hurd:/# updatedb hurd:/# /servers/socket/2: Der Übersetzer ist gestorben -- Message-ID: <86d7f2d2xe.fsf@woodstock.huemmer.net>
Attachment:
pgpLaz5SrK3u_.pgp
Description: PGP signature