Hi Paul,
I've uploaded a new package which should address your packaging concerns.[1]
I find a symbols file a bit overkill for a library which is not going to
be developed any further in the forseeable future, but I've added one
anyway. - You've pointed out a few things I might discuss with upstream,
and I certainly will when I have the time.
A few direct responses to your remarks:
> You seem to have radically altered the install procedures, why not
> install to debian/tmp in the install target and use dh_install like
> the current version does instead of manually moving stuff around?
I think this one is just personal preference. (I've chosen to do four
mv calls instead of adding three more .install files and am mostly
moving whole directories.) The 1.8 package version even used dh_movefiles. ;)
> There are several lintian complaints:
Lintian (even with -IE --pedantic) is now down to
] P: libdumbnet1: no-upstream-changelog
] P: python-dumbnet: no-upstream-changelog
which I can't remedy myself.
> Who is hesso@pool.math.tu-berlin.de?
Me, as at least the changelog and the key I'm signing these mails with
should show. I don't like the whole debian-list volume hitting my univer-
sity address, so I'm writing these mails from a different account.
> [/usr/share/doc/{packages}]
I'm sharing the doc directory between the lib and the dev package, and as
the difference in files I'd like to install in those directories is so
small I'm not inclined to change that.
> Likewise, the package descriptions should reflect the audiences.
> libdumbnet-dev/python-dumbnet probably needs a fair bit of information
> but libdumbnet1 will probably always be automatically installed so
> needs vastly less information.
How could I convey less information? Only include the single sentence
"libdumbnet provides [...] networking routines."? That wouldn't satisfy
me as a user at all. The items give me an idea of what that library
actually does and why another package might need it - I don't want to
remove them.
I've changed the short description to make the packages distinguishable.
> A single autoreconf call can replace the
> aclocal/autoheader/autoconf/automake calls (but not the libtoolize one
> IIRC).
If I'm forced to rerun the autotools in order to keep the diff/patchset small,
I'd rather list explicitly what I'm calling and which parameters I use.
PS: I've activated the test suite, but it has its limitations and might
not be of as much use as you might have intended. (Another thing upstream
should take care of, at least partially.)
Regards,
Jan
[1]: http://www-pool.math.tu-berlin.de/~hesso/deb/libdumbnet_1.12-1.dsc
Attachment:
signature.asc
Description: Digital signature