On 14.11.1998., at 13:00, Adam Di Carlo wrote: >Please don't be anglocentric. Just say "common language". >| distribution is its' package system.
Okay. >| libg++272 - the C++ libraries. Fakeroot needs them. > >No longer true. I didn't use it myself (I do packages at home so simple su and being careful is enough). Still, there is another dependency I have to insert: libstdc++2.9, and that one doesn't exist/work (?) in hamm - and that is a big problem. Libtricks also requires that lib. Maybe I should suggest that fakeroot should be downloaded as source, and recompiled for hamm locally - and so much for simplicity... :( Or maybe it's best to postpone making this chapter until slink (with both these packages on every CD) becomes stable? >| debmake - the most used set of tools for creating Debian packages. You >| don't really need it to create a package, just as you don't really >| need debhelper, but its good to have it around. > >No longer true. Do you have any reason to say that I should remove this reccomendation? Maybe I should put debmake (and devscripts? see below) in 'suggestions'? >| developers-reference - information for people who want to become >| official Debian maintainers. > >Actually, the point of the developer's reference is to be an >*official* reference for all matters not specifically about the >technical details of packaging. As such, it goes into a lot of detail >about the structure of the archive, how to rename, orphan, pick up >packages, how to do NMUs, how to manage bugs, when to upload to >stable, unstable, frozen, and experimental, etc. > >Actually there are many parts of the developer's reference which you >can copy and paste (or boil down) for your document there. Well, that sentence was a leftover from one of the previous documents. Can I take your words, rephrase them and put them in that description? >Zipping ahead: > >| 5.2 the `rules' file > >I feel that you need more explanation of the debian/rules file. Ok. And by the way, should I remove the minor numbering (5.1 and 5.2) because I don't mention it in the table of contents? >Briefly explain Makefile targets and the various dh_* scripts. Makefile targets are going to be as brief as possible since I don't know much about them :) dh_* scripts are explained in that same file, not all of them though: --- Lines 45-67 run several small utilities from the debhelper package that do things to your package to make it conform to Debian policy. The names start with dh_ and after that you can see what every little util really does: testdir and testroot check that you are in the right directory, install* install Debian files under debian/tmp, strip strips debugging headers from executable files to make them smaller, compress gzips man pages and documentation larger than 5kb, fixperms checks and fixes invalid permissions in debian/tmp directory, suidregister sets up files to register setuid executables with suidregister(8) program, installdeb copies package related files under debian/tmp directory, shlibdeps calculates dependencies of the executables, gencontrol generates and installes the control file, md5sums generates MD5 checksums, and finally, builddeb builds the debian package. --- Should I make another chapter about it or to leave it in the file with 'rules'? >| dirs >| >| This file specifies the directories which our package will create. By >| default, it looks like this: > >Actually, 'debian/dirs' is only used by dh_installdirs (see the man >page). Interestingly enough, your example debian/rules file doesn't >include dh_installdirs! Sorry, another leftover from old documents. But it will be mentioned (my package is in optional section - all the directories it needs are already created by base and x11 packages) >You also need to add a section talking about maintainer scripts. And those are the ones from 'devscripts' package? I see no use for most of them to a new maintainer (because I am also one :), in the document I don't use build/release but dpkg-buildpackage/dupload. Only dch would be of some use, but if maintainer knows how to edit Makefiles and C sources, he'll know how to edit changelogs. Oops, another two ideas - describe what to do when upstream source gets updated and describe how to actually edit changelogs. Or maybe I'll describe it all with devscripts... I'm really puzzled now :) >> To Adam Di Carlo: I'm planning to do it with sgml for 1.0 but I >> think the contents is more important than the form. And about DDP - >> I could join, but I'll first have to use SGML, and to learn how to >> use CVS (what a lamer). > >Hey, don't worry about it. We really encourage you to use DDP >resources since it helps us try to cohere the efforts which are out >there. But it's meant to be a resource which *helps* Debian >documenters. I.e., if you maintained the documentation out of CVS, I >could always check out the most recent copy and edit it and send you >patches, or, with your permission, even commit changes. > >I'd be happy to help you set up CVS when you're ready, but I agree >that getting content out there is more important right now. Until then, I'll just update the HTML version byhand. And I'll gladly apply any undisputable patches sent to me by e-mail (preferably unified diffs). P.S. Expect version 0.11 out by midnight. /*- enJoy -*/\*- http://jagor.srce.hr/~jrodin/ -*/
