Re: Debian New Maintainer Guide 0.1
In article <[🔎] 199811142014160410.00D75C07@cibalia.gkvk.hr>, "Josip Rodin" <joy@cibalia.gkvk.hr> writes:
> On 14.11.1998., at 13:00, Adam Di Carlo wrote:
>> | 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?
Well, you should be writing for slink anyhow, since any Debian
developer needs to be running it. We're not really accepting packages
for hamm anymore. See the Developer's Reference for why not.
>> | 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'?
Debmake (aka debstd) is officially deprecated, but not officially
sanctioned against. You should mention that. Devscripts, while I'm
not completely happy with it, is ok. I wouldn't even *suggest*
debmake, personally; no discredit to the current maintainer, who is
doing a great job.
>> | 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?
Of course. You don't even need to credit me... ;)
>> 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?
Just move to debiandoc-sgml and you don't need to worry about it.
You're doing all this HTML work to simulate debiandoc-sgml... it's
really a waste of your time.
>> 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:
[...]
> builddeb builds the debian package. ---
> Should I make another chapter about it or to leave it in the file
> with 'rules'?
It goes with 'rules'. I just think that there should be, like, a
little description list (<dl>) giving short one-liners about what all
the dh_* scripts are for, and referring ppl to the man pages for more
info. (BTW, debiandoc-sgml has <manref> tag too!)
[...]
>> 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.
No, I'm talking about postinst, preinst, postrm, prerm. Just tell the
new user to try to avoid maintainer scripts if they possibly can (they
are complex) -- point them to the Packaging Manual.
> 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.
Yes -- I use debian-changelog-mode and emacs, but... ;)
> Or maybe I'll describe it all with devscripts... I'm really puzzled
> now :)
Well... hmm. I don't think devscripts really needs a lot of
treatment. Maybe. Do you go into 'build' and all that? I don't use
that stuff.
See the brief descriptions of maintainer tools at the end of the
developer's reference also.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: