Re: My first packages -- some questions.
Hi Guys!
I've put my packages back together without debmake helper scripts, and
I feel much more confidant now that I know what is going on. A big
help was Igor Grobman's unfinished work, the "Debian Programmers
Manual"
http://www.pics.com/~igor/debian/programmer.html/index.html
which contained this execution tree:
dpkg-buildpackage
dpkg-parsechangelog
rules clean
dpkg-source
rules build
rules binary
dpkg-shlibdeps
dpkg-gencontrol
dpkg-deb
dpkg-genchanges
[Igor, I swapped ``dpkg-source'' and ``rules clean'' and added ``rules
build'' here.]
Igor said that this was an old project that he never finished and that
better things were being written now. I'm sure that I haven't managed
to track down all the new-maintainer documentation out there, but
Igor's document contained a lot of useful information I had not seen
elsewhere (such as this execution tree) that seemed to fill the niche
between the "Debian Packaging Manual" and the several packaging
tutorials which lean toward debmake/debstd.
Manoj's sample rules files helped a lot too. I like their style, and
I borrowed a lot from them. He offered to email them to those who
wanted wished. To help cut down on his email load, I would be happy
to forward them to anyone who asks. The uuencoded file is about 230k.
Here a just a couple of more questions.
1. For the elisp-manual package (this is the info version of the 700
page 2 volume manual available from FSF) I changed Section/Priority
from editors/extra to doc/optional. (This is appropriate isn't
it?) This shows up in the *.changes file (both on the md5sum lines
and as a changelog entry ) -- is that all I need to do? The
package was removed from hamm a couple of weeks ago (since it was
in old source format) so I don't think that I need do anything else
to get it out of its old section.
2. The elisp-manual package is funny in that the upstream package
comes with pre-built info and dvi files in addition to the Texinfo
source. (The README does not mention this, but it is not just a
fluke of this version as previous versions also did this.) What is
weird about version 2.4.2 is that the pre-built info files (but not
the dvi file) is build from a different version of the source --
version 2.4b. The difference between versions 2.4b and 2.4.2 is
slight, consisting of the rewording of a dozen and a half
sentences. (The pre-built info files were also build with a much
older version of makeinfo, which also changes their format.)
Anyhow, to avoid messing with the pre-built info files, I built the
ones for the Debian package in a subdirectory debian/build-info.
Is that cool? (It works, I'm just wondering how appropriate it is.)
3. I originally planned to ask someone to review my packages before I
uploaded them, but I do feel much more confidant now. I have
uploaded them to my home directory on master: /debian/home/kirk
-rw-r--r-- 1 kirk Debian 2948 elisp-manual_19-2.4.2-1.diff.gz
-rw-r--r-- 1 kirk Debian 648 elisp-manual_19-2.4.2-1.dsc
-rw-r--r-- 1 kirk Debian 555204 elisp-manual_19-2.4.2-1_all.deb
-rw-r--r-- 1 kirk Debian 1201 elisp-manual_19-2.4.2-1_i386.changes
-rw-r--r-- 1 kirk Debian 1937099 elisp-manual_19-2.4.2.orig.tar.gz
-rw-r--r-- 1 kirk Debian 2277 emacs-lisp-intro_1.05-1.diff.gz
-rw-r--r-- 1 kirk Debian 651 emacs-lisp-intro_1.05-1.dsc
-rw-r--r-- 1 kirk Debian 195668 emacs-lisp-intro_1.05-1_all.deb
-rw-r--r-- 1 kirk Debian 1146 emacs-lisp-intro_1.05-1_i386.changes
-rw-r--r-- 1 kirk Debian 190408 emacs-lisp-intro_1.05.orig.tar.gz
Although I don't feel the need for someone to check them out
anymore, I would certainly still appreciate it if some chose to
take the time to do so.
4. I'll move them over to Incoming late this evening if nothing bad
turns up before then. I know that new upload policy is being
discussed (and I did use the ``Closes: Bug#'' syntax), but my
understanding is that I still need to close the bugs and mail the
.changes file to debian-devel-changes myself. I assume that I
should do the latter as soon as I move them to Incoming and the
former after they have been installed in the hamm tree. Right?
Thanks again to the help. I have heard this expressed before, and it
was certainly true for me; the packaging process seems rather
confusing at first, but it is actually quite easy once you figure
things out. (Yeah, yeah, I know that these were two really simple
packages -- no executables, only info files -- but now I am ready for
more something more complicated.)
Kirk Hilliard
Reply to: