Getting close to releasing my first .deb's... What's next?
I'm working on creating .deb packages for one of my projects, with the
eventual goal of having it included in the debian distribution.
I've browsed through the policy manual, new maintainers guide, etc, and I've
successfully created a "debian/" directory in my project that allows debuild
to produce the files here:
http://www.crackerjack.net/mod_bt/experimental_debs/
These files aren't signed (yet). I know that's the next step. :-) But then,
what about after that.... Before I seek a sponsor I'd like to have all the
spit-n-polish done and have these packages as close to "perfect", but
there's a few issues I'm not sure how to deal with:
1. lintian complains that I don't have manpages for my executables.
This is because the project is still young and they haven't actually been
written yet. However, the executables aren't the meat of the project,
they're just nice-to-haves and some may disappear/get re-arranged. Is the
lack of manpages for these tools a blocker? I've noticed several packages
that get installed with a generic "no manpage was written for this" manpage,
can I just do that for now?
2. "php5-apache2-mod-bt". This package actually needs php5, apache2,
and mod-bt to be installed and links them all together, providing a php5
interface to inspect the data of a running mod_bt tracker on an apache2
server. Should the ordering of the name be rearranged? Like
"libapache2-php5-mod-bt" or something?
3. Currently, one set of documentation is generated for all of
mod_bt's components. All of the components are part of the same distribution
and released under the same license (Apache 2.x). I'm guessing I should
place this documentation in the deepest common dependancy (libbtt) and
symlink the other package's share/doc/ directories over there. I saw that
libzvt does that with it's -dev package.. Is that a generally accepted
practice? Even if we're talking about 8 different .deb's?
4. W: libbtt: non-dev-pkg-with-shlib-symlink usr/lib/libbtt.so.0.0.0 usr/lib/libbtt.so
Should I care?
5. W: libbtt: package-name-doesnt-match-sonames libbtt0
I suppose I should care about that, but how does it pan out for the
packages that depend on it? Should libbtt-utils be named libbtt0-utils? Or
should it stay named the same and always depend on the libbttX package it
was built against?
There's a few other misc. lintian warnings i'm seeing that I know
how to fix, I'm going to work through those... but I'd love any advice on
how to proceed with those above, as well as any other suggestions people may
have... I've put off debianizing mod_bt for a loooong time now because the
debian/ folder made me nervous, but I think I'm finally getting a handle on
it. :)
Also, one other thing; once mod_bt gets injected into debian, I was
toying with the idea of having the debian BTS be the mod_bt's official bug
tracking database. This would save having to maintain two bug lists, forward
things upstream, etc., especially because as of 0.0.15 I'll be distributing
the source debian-ready. To get used to it I've set up a debbugs server to
play with (http://bts.yi.org/). Is it acceptable to use the debian bug
database as the official bug database for a package that's available in
debian, but also available elsewhere? (eg; if I made RPM's, etc)
Thanks,
Tyler
Reply to: