Re: Getting close to releasing my first .deb's... What's next?
Hello Tyler,
On Tue, April 25, 2006 00:01, Tyler MacDonald wrote:
> I'm working on creating .deb packages for one of my projects, with the
> eventual goal of having it included in the debian distribution.
Then you've come to the right place for help :)
I'm out of town, so just some general comments here:
Your package is a "Debian native" package, i.e. without an orig.tar.gz.
That's not considered a good idea unless it's really Debian-specific.
Normally you'd have an .orig.tar.gz from upstream and a .diff.gz with the
Debian-specific changes.
> 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?
Just include no manpage at all. Don't silence Lintian for it, because man
pages need to be made eventually. However, will the binaries really change
that much that it creating man pages would be wasted effort? Just some
general documentation is already a lot more helpful than nothing at all.
My advice would be to include as much of a manpage as is reasonable
looking at what you expect of the future of that binary.
> 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?
I'm not entirely sure since I'm not well aware of the specifics of your
module. If other people on this list can't help with that, you could
consider contacting e.g. the debian-apache list for a second review of
your package.
> 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?
Sure. Just make sure that users have the documentation they need when they
install just one of the packages, and that they have all information
required by policy (Debian changelog).
> 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)
Please don't include the 'debian/' directory in the upstream tarball. This
is just a little convenient when maintainer == upstream, but as soon as
either one changes, this can lead to confusion when the debian-diff is a
diff over an existing debian dir. There's been quite some discussion about
this previously.
You can use the debian BTS as your upstream bts though, as long as you're
keeping it in shape of course :)
Good luck with your package!
Thijs
Reply to: