Re: Debian New Maintainer Guide 0.1
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/ -*/
Reply to: