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